[SIPForum-techwg] Could to-tag in 200 OK response be differentwith the to-tag in 180 ringing?

[mike xu]

Hi Vipul,

Yes, you are right.
Its all because of my EP isn't totally RFC3261 complied... :-)

Thanks & best regards,
Mike

On 7/30/07, 라스토기 <vipul.rastogi at samsung.com> wrote:
> Hi,
>  I don't thing there is any problem. 180 rining is just provisiong message and as of yet dialong is not made. 200 makes a dialog. so in case 180 & 200 OK has different to-tag, EP should ignore 180 to-tag & make dialog with 200 OK to-tag.
> Hope this will work for you,
> bye
> vipul rastogi
>
> Engineer, Business Management Team
>
>
> ----- Original Message -----
> From: "mike xu" <clumsguy at gmail.com>
> To: "Dale Worley" <dworley at pingtel.com>
> Cc: <techwg at sipforum.org>
> Sent: Monday, July 30, 2007 11:37 AM
> Subject: Re: [SIPForum-techwg] Could to-tag in 200 OK response be differentwith the to-tag in 180 ringing?
>
>
> > Hi Dale,
> >
> > Thank you for your reply.
> > It seems that the transaction/dialog match part in the UAC which I
> > used need to be enhanced to deal with such "forking" case.
> >
> > Thanks again,
> > Mike
> >
> > On 7/27/07, Dale Worley <dworley at pingtel.com> wrote:
> >> On Fri, 2007-07-27 at 12:49 +0800, mike xu wrote:
> >> > Do you know that in RFC3261, could the to-tag in 200 OK be different
> >> > with the one in 180 ringing?
> >>
> >> It is allowed, but it does not mean what you might expect.  Each to-tag
> >> represents one dialog.  The 180 has a to-tag value, and it is part of a
> >> dialog.  The 200 has a different to-tag value, and so it is part of a
> >> *different* dialog.  The 180's dialog never succeeds (because the dialog
> >> never returns a 200 response), and eventually the UAC deletes knowledge
> >> of it.  So from the UAC's point of view, this is an example of forking.
> >> (In general, a UAC must be able to track multiple early dialogs until it
> >> receives a 200.  After that, it may also receive 200 responses for other
> >> forks of the INVITE, which it must either handle or terminate by sending
> >> BYE.
> >>
> >> > Below is the case which I met, in step F1 (180 ringing), callee
> >> > generated one to-tag (46bf8) while in step F2 (200 OK) the sip server
> >> > generates a new to-tag which is "as5123fc8f", and my sip endpoint
> >> > didn't match this 200 OK response, the sip server will resend 200 OK
> >> > and I obveriously couldn't hear the voice mail info.
> >> >
> >> >    Caller        SIP_SERVER       Callee
> >> >      |                |              |
> >> >      |       INVITE    |             |
> >> >      |------------->|  INVITE      |
> >> >      |    (100 Trying)  |----------->|
> >> >      |<-------------|              |
> >> >      |                |180 Ringing F1 |
> >> >      |   180 Ringing   |<-----------|
> >> >      |<-------------|              |
> >> >      |                |   CANCEL     |
> >> >      |                |----------->|
> >> >      |                |   200 OK     |
> >> >      |                |<-----------|
> >> >      |                |487 Req Cancel |
> >> >      |                |<------------|
> >> >      |                |     ACK       |
> >> >      |                |------------>|
> >> >      |200 OK(SIP/SDP) F2|               |
> >> >      |<-------------|               |
> >> >      |    ACK         |               |
> >> >      |------------->|               |
> >> >      | voicemail RTP   |               |
> >> >      |<===============||               |
> >> >
> >> > Does any body know that the new to-tag in F2's 200 OK response is
> >> > valid or invalid? Does it comply to RFC3261?
> >>
> >> It looks like SIP_SERVER is doing what it should -- the 200 is
> >> establishing a different dialog than the one that the 180 was reporting
> >> on.
> >>
> >> Dale
> >>
> >>
> >>
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg
> >
> >