|Summary:||ASTERISK-20418: peer Call-ID change after core reload - SIP provider requests that we maintain Call-ID|
|Date Opened:||2012-09-14 02:11:33||Date Closed:|
|Versions:||10.7.0 13.18.4||Frequency of|
|Environment:||FreePBX distro (Asterisk 10.7.0 built by root @ jenkins6.schmoozecom.net on a x86_64 running Linux on 2012-08-13 19:26:17 UTC)||Attachments:|
|Description:||registration Call-ID changes after core reload|
[Moved the following from the Reference Notes section]
Each time we execute an core reload (on asterisk 10.7.0 / FreePBX distro) the registration Call-ID changes (new CSeq).
This behavior causes problems with our sip provider. Every time a core reload has been given this is a new binding on the provider side (opensips). So for incomming calls a INVITE is sent per binding (as long as the expire time is set for the former registration).
We think this behavior was different in asterisk 1.4 because we never had complaints about strange behavior after reloading asterisk.
Would it be possilble to keep the same registration Call-ID after an core reload or set a static Call-ID for peer registrations?.
Also see ticket http://www.freepbx.org/trac/ticket/5967
|Comments:||By: Rusty Newton (rnewton) 2012-09-19 18:11:22.314-0500|
We don't currently know that this behavior was any different in older versions of Asterisk. Acknowledging as a feature request for interoperability since your provider is requesting it. If you can find any reference to show that more than just this one provider requires this behavior, that would help motivate developers to make it higher priority.
Probably should add the name of the SIP provider to the description to help others who find this report.
By: Edwin (solliecomm) 2012-10-08 02:08:00.032-0500
The provider uses Opensips, so it is not 'provider' related. Since the 1.8 version we also hear complaints from asterisk users using other providers. I already had contact with Bogdan (opensips), he points to asterisk to solve the problem.
Since the problem is logical - an other Call-ID in a registration is another client so another INVITE - it should solved (asap).
If you need sip trances we can provide.