[asterisk-dev] Custom SIP headers and reinvites

[Bala Neelakantan]

Thanks,

Neel

 

 

> -----Original Message-----

> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-

> bounces at lists.digium.com] On Behalf Of Watkins, Bradley

> Sent: Tuesday, April 17, 2007 8:56 PM

> To: Asterisk Developers Mailing List

> Subject: [asterisk-dev] Custom SIP headers and reinvites

> 

> There seems to be a timing-based issue with custom headers and

> reinvites.

> 

> What happens is that if there is any kind of delay in processing a call

> to SIP_HEADER (e.g., the extension is in Realtime or you have a Wait(x)

> before Set), you lose access to the custom headers.  In my situation,

> there is a pair of Asterisk boxes, with one calling the other (the first

> one having been called by a SIP phone).  The first box essentially

> immediately issues a reinvite so that media is directly from the phone

> to the second Asterisk box.  If dialplan execution is fast enough, you

> can successfully acquire the headers in the original invite.  But as

> stated, any delay will cause the SIP_HEADER call to look for headers in

> the reinvite, and you lose since they aren't sent.

 

The Re-INVITE cant be sent before the original INVITE is completed.  So, a
INVITE - Final Response - ACK should be done.  So, in your case, the first
Asterisk Box should wait before issuing Re-INVITE.

 

> 

> I guess what I'm looking for is some guidance on what the correct

> behavior is here.  Obviously, these headers should be available one way

> or the other.  The question is whether the reinvite should have the

> custom headers or whether they need to have some more persistant storage

> at the receiving end.  I'm inclined to say the latter, as it's possible

> that you could have this same issue with other B2BUA's in a similar

> scenario.

>

 

The original INVITE transaction should still hang around to handle any
possible retransmits.  The CSeq number should help here, so that you are
looking at the original INVITE as opposed to Re-INVITE.  

 

> FWIW, this is the root cause for the bug I describe in:

> http://bugs.digium.com/view.php?id=9516

> 

> I'm actually using Realtime, hence the description there (which after

> some more debugging on my end is quite misleading, I'm afraid), but a

> Wait(.5) using regular extensions.conf has the same effect.  Heck, I

> tried Wait(.01) and it still happens, though I can't say with any (and I

> mean *any*) authority what Wait's resolution is.  Of course, YMMV

> depending on the speed of system you're running the instances of

> Asterisk on.

> 

> Regards,

> - Brad

> The contents of this e-mail are intended for the named addressee only. It

> contains information that may be confidential. Unless you are the named

> addressee or an authorized designee, you may not copy or use it, or

> disclose it to anyone else. If you received it in error please notify us

> immediately and then destroy it.

> _______________________________________________

> --Bandwidth and Colocation provided by Easynews.com --

> 

> asterisk-dev mailing list

> To UNSUBSCRIBE or update options visit:

>    http://lists.digium.com/mailman/listinfo/asterisk-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070419/a7755e89/attachment-0001.htm