On Tuesday, April 09, 2013 1:31 PM, Nick Khamis wrote: > As I see asterisk rewrites the callid unexpectedly when initiating the > INVITE with the SIP trunk (trace packet 4).
[...] > Asterisk has mapped the call with the two different ids together. Nick, As Joshua has already tried to explain to you, Asterisk is a B2BUA, not a SIP proxy. This is by virtue of its nature and origins as a technology-agnostic PBX. It is not "rewriting" the Call-ID. It's generating an entirely new one because the INVITE that it generates is considered by Asterisk to be a competely new/separate call leg. It then maintains a table of which call legs are "bridged" together into a single call, regardless of the underlying channel technology. Because of how Asterisk works under-the-hood, it is also impossible for it to "pass on" Record-Route header fields to the other leg of the call. It will, however, take appropriate action in passing any signalling events downstream (for example, in your case, a "BYE" will be sent to one call leg if it is received on the other, but NOT because it is proxying it; to boil it down, internally, the received "BYE" is translated to a generic "hang-up" event which the SIP channel driver takes and uses to generate a completely new "BYE" from scratch on the other leg). I concur with Joshua: this is not an Asterisk problem, and what it is doing is completely reasonable. I suspect that the "leads" you are chasing in this investigation will turn out to be a red herring. -- Nathan Anderson First Step Internet, LLC [email protected] -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
