All,
After reading RFC 3725 BCP for 3rd Party Call Control it created an
interesting question.
Is an SDP session-id tied directly to a SIP dialog and cannot change in
the SIP dialog?
RFC 3725 seems to imply that but I cannot find any documentation that
specifically
states this. (Because of the mapping of the o= line ).
Consider the following scenario when Early media is provided and the
call is forwarded to another location. At Answer an Empty Re-Invite is
used perform
End to End SDP negotiation and the B2BUA proxies the SDP (without
change) to
complete the Path minimization. This causes a change in the SDP session
ID to the
originator also allowing for payload type numbers to be re-mapped.
Without the
possibility of changing the SDP session-id there are cases, mainly in
inter-vendor situations,
that cause collision of Dynamic Payload type numbers. Unfortunately
trying to do all the
remapping of payload types in the bearer stream is not a viable option.
In addition to this scenario, there are scenarios (Blind Transfers for
one) that a newly
added leg is originated with an Empty Initial Invite requiring the Far
office to send an
initial offer and now how do you match up SDP media lines and payload types
numbers for these?
If changing the session-id is not the correct solution how do is this
solved?
RFC 3264 states that payload type number MUST not change within a session
(i.e. SDP session) but it states that the Payload type number do not
have to be
the same in both directions and thanks to H248 this is the case.
If I extend what is not in RFC3264 to say that if the upper layer
protocol provides
a new session-id within a SIP dialog then I can re map the Payload type
numbers
and the SDP Session-id and new SDP version number are considered valid and
everything works.
What is the opinion of the BCP 3725 authors or those working with SIP RFCs?
Thanks
Dave Robinson
Alcatel-Lucent
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
