Hi all,
I would request someone to let me know what should be the handling in case UAC
receives a bad 200 Ok message. For example, in case SDP format is not ok.
Thanks in advance
Regards
Sarju
# 9810304396
----- Original Message -----
From: Rayees Khan
To: Stephen Paterson
Cc: SIP Implementors (E-mail)
Sent: Monday, June 12, 2006 11:57 PM
Subject: Re: [Sip-implementors] Session timer - how to indicate the session
hasnot changed
Hi Stephen,
This is a protocol violation, however, the handling of such things is highly
local to the Endpoint. An EP can choose to just check the o-line and decide on
the basis of this whether to process rest of SDP or not.
regards
Rayees
[EMAIL PROTECTED] wrote: -----
To: "SIP Implementors (E-mail)" <[email protected]>
From: Stephen Paterson <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 06/12/2006 11:31AM
Subject: [Sip-implementors] Session timer - how to indicate the session
hasnot changed
Hi all,
The last paragraph of section 7.4 of RFC 4028 states:
'It is RECOMMENDED that the UPDATE request not contain an offer [4], but a
re-INVITE SHOULD contain one, even if the details of the session have not
changed. In that case, the offer MUST indicate that it has not changed. In
the case of SDP, this is accomplished by including the same value for the
origin field as did previous SDP messages to its peer. The same is true for
an answer exchanged as a result of a session refresh request; if it has not
changed, that MUST be indicated.'
What happens when the refresher sends an offer with an unchanged origin
field, receives a 200 OK with an unchanged origin field but an 'm=' line
that was present in the most recent offer/answer exchange is missing from
the UAS response?
My gut feeling is that the UAS is out of spec (and the entire SDP should be
unchanged) but according to the quote above, only the origin field needs to
be unchanged in order to indicate that the session details are also
unchanged.
At the moment this causes problem for our SIP implementation as it has no
control over the media. It simply raises an event to the application that is
controlling the media to indicate that the session parameters have changed.
We don't want to be doing this for session refresh requests unless a genuine
offer/answer exchange has been negotiated during the transaction.
If the UAS is out of spec, how should the UAC behave?
If not, is there anywhere in the RFCs that specifies more clearly how to
identify that a media session is unchanged? I haven't been able to find
anything in SIP, SDP, Session Timer or Offer Answer (which isn't to say the
answers aren't there somewhere).
It may well be the case that I just have to change our logic and ignore all
of the SDP if the 'o=' is unchanged. Part of my query is to ensure that, if
I do this, I don't break anything elsewhere.
Cheers
Steve
Steve Paterson
Software Engineer
Aculab
Tel: +44 (0) 1908 273866
Fax: +44 (0) 1908 273801
Email: mailto:[EMAIL PROTECTED]
Website: http://www.aculab.com
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
*****FSS-Private *****" DISCLAIMER: This message is proprietary to
Flextronics Software Systems Limited (FSS) and is intended solely for the use
of the individual to whom it is addressed. It may contain privileged or
confidential information and should not be circulated or used for any purpose
other than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. FSS accepts no
responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus."
------------------------------------------------------------------------------
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
