For the first question, see the following bug logged against 3262 - http://bugs.sipit.net/sipwg/show_bug.cgi?id=745
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Paul Kyzivat Sent: Monday, January 12, 2004 8:53 AM To: Krishna Kanth T Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Few doubts in sip protocol Krishna Kanth T wrote: > Hi, > > I have few doubts in sip-protocol. It will be helpful if any one can > help me in clearing my doubt. > > 1. RFC 3261 says in 13.2.1 that :- > "If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is correlated to > that INVITE.". > - Does this mean that if an INVITE is sent with SDP(offer) and > then if reliable provisional response (180/183/...) comes with SDP, then > the SDP in reliable provisional response must be considered to be answer > and any SDP that comes in 200 OK should be blindly ignored ? To answer this you must take both 3261 and 3262 into account. Based on 3262, if you sent the answer back in a reliable provisional, then the offer/answer exchange is complete. So unless another offer/answer cycle is initiated the 200 OK should not contain an SDP session description. 3261 does permit an answer in an unreliable provisional, in which case it should be repeated in the 200. This covers the case where the provisional doesn't arrive. In that case, if the UAC receives the provisional with the answer it should ignore the one in the 200. For consistency and robustness, it probably makes sense for the UAC to also ignore a session description in the 200 when there was a prior answer in a reliable provisional. But AFAIK this isn't standardized behavior. > 2. RFC 3261 says in 13.2.1 that :- > "The UAC MUST treat the first session description it receives as > the answer, and MUST ignore any session descriptions in subsequent > responses to the initial INVITE." > > - Does this mean that if an INVITE is sent with SDP (offer) and > then if it receives a non reliable provisional response with SDP and > then it gets a 200 OK with SDP, then only the SDP in non-reliable > provisional response must be considered as answer and the SDP in 200 OK > must be blindly ignored ? Yes. > 3. Is the following scenario possible :- > > A B > | | > | INVITE (SDP OFFER) | > |--------------------->| > | | > | | > | 183 (SPD ANSWER) | > |<---------------------| > | PRACK (NO SDP ) | > |--------------------->| > | PRACK 200 OK(NO SDP) | > |<---------------------| > | | > | | > | | > | 183 (SDP OFFER) | > |<---------------------| > | PRACK ( SDP ANSWER) | > |--------------------->| > | PRACK 200 OK(NO SDP) | > |<---------------------| > | | > | | > | | > | 200 OK(NO SDP) | > |<---------------------| > | ACK (NO SDP ) | > |--------------------->| > | | > In the above diagram, I specifically wanted to know whether calle party > (B) can send an OFFER SDP in the second reliable provisional response ? I believe this is OK. > 4. RFC 3261 says in 19.1.1 that :- > "Even though an arbitrary number of URI parameters may be > included in a URI, any given parameter-name MUST NOT appear more than once." > > If this is the case, then how is tel uri format mentioned in > RFC 2806 compatible with above definition. Tel uri says that :- > > global-phone-number = "+" base-phone-number [isdn-subaddress] > [post-dial] *(area-specifier /service-provider / future-extension) > area-specifier = ";" phone-context-tag "=" phone-context-ident > phone-context-tag = "phone-context" > > Here he says that area-specifier (which is nothing but a tel - uri > parameter) can appear more than once. But the above definition is not > compatible with that of given in the rfc 3261. What to do in this case ? > How to handle multiple tel-uri parameters with the same parameter name ?. 19.1.1 only pertains to sip and sips uris, not tel. When a tel uri is mapped to a sip uri, all of those "parameters" in the tel uri go into the user part of the sip uri. (Before the @.) They are not "uri parameters" as defined for the sip uri. Paul _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
