> On Wed, 2009-06-10 at 13:41 -0400, Raymond Dans wrote:
> > In my investigation of XX-5913 involving a call setup
> between a remote
> > worker and an AudioCodes Gateway, I've noticed some oddities on the
> > Gateway side of things and require some clarification on
> the SIP spec.
> >
> > The scenario is as follows:
> >
> > 1. Remote worker initiates a call that is to go out the AudioCodes
> > Gateway.
> > 2. Gateway 200 OK's the call but this response never makes
> it to the
> > Remote Worker and
> > as a result no ACK is sent for the 200 OK.
>
> Do we know why that doesn't get through? Was the phone-proxy
> traffic TCP?
200 OK is sent over UDP to the right port... The remote worker is
fronted by an old Intertex which may have its SIP ALG running so god
know what's happening there. Everything looked ok from our end.
>
> > 3. Remote worker CANCELs the INVITE after about 1 minute since the
> > INVITE was sent and the Proxy 200 OK's it right away. Call
> State Event
> > generation doesn't look at CANCELs and even if it did wouldn't have
> > seen this one since the Proxy responded right away.
>
> > Call State Event generation (in the Proxy), believes the call was
> > established because of the 200 OK and because no BYE was ever sent,
> > the call is still believed to be active (until CDR sees the call in
> > active state for 8 hours at which point it sets the
> completion state
> > to Unknown and closes the record).
> >
> > My questions regarding the SIP spec (RFC 3261) are as follows:
> >
> > 1. In section 13.3.1.4 "The INVITE is Accepted", it states that the
> > UAS when sending a 2XX response must ("it is necessary") to
> retransmit
> > the 2XX response at a specified interval until the ACK to this
> > response arrives. In addition, this retransmission must be done
> > independent of "whatever transport protocol" is used to
> send the response.
> > Is it correct to say that even if the transport protocol is TCP
> > (which is reliable), then the AudioCodes Gateway should have been
> > re-transmitting these 200 OK's because no ACK was ever
> seen? If this
> > is the case, then I believe a new issue should be opened
> against the
> > AudioCodes.
> >
> > 2. In the same section "The INVITE is Accepted", it states
> the if the
> > server retransmits the 2XX response without ever receiving
> an ACK, the
> > dialog is confirmed, but the session SHOULD be terminated
> by sending a
> > BYE.
> > Does anyone know why its SHOULD and not MUST? If it was
> MUST, then
> > CDR would have closed the call record when the BYE was seen.
>
> There may be some historical reason having to do with 2543
> compatibility, but I don't know. You could ask on the
> sip-implementors list (if you'd rather not subscribe just to
> post that question, let me know and I'll post it) to see if
> someone remembers.
>
> More importantly, one has to be careful when reading SHOULD
> (or the equivalent RECOMMENDED); the official text says:
>
> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course.
>
> the correct interpretation of this is really to treat it as
> MUST unless there is really really good reason why in your
> particular circumstances you can't or shouldn't _and_ you
> know that it won't cause interoperability problems to do so.
> So, for example, if you had a private extension that allowed
> you to recognize that you didn't need to follow a MUST
> because your peer also supports the extension and doesn't
> need you to, then you could ignore it. This isn't a case
> like that, so I think an issue with Audiocodes is warranted.
>
> As for the issue, I'd just resolve it as External System
> Error (unless the non-delivery is our fault, in which case
> link this issue to whatever we're using to track that).
>
>
> _______________________________________________
> sipx-dev mailing list [email protected] List
> Archive: http://list.sipfoundry.org/archive/sipx-dev
> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
> sipXecs IP PBX -- http://www.sipfoundry.org/
>
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
