headers
Christer Holmberg (JO/LMF | 1 Sep 2004 09:07
Picon
Favicon

RE: Clarification regarding Offer/Answer Model


Hi,

>I had a couple of questions regarding the Offer/Answer model. 
>Assume the following call flow:
> 
>1. User A sends INVITE with SDP to User B.
>2. User B sends a 183 Call Proceeding with SDP Response. 
> 
>Case (1):
>======
>If the 1xx response sent in step (2) above be sent unreliably 
>(no PRACK support),  is it legal for User B to change SDP in 
>the 2xx response since this is the FIRST reliably-sent 
>response sent by B ?

No.

>Case (2):
>=======
>If the 1xx response sent in step (2) be sent reliably and say 
>this is acknowledged with a PRACK/200 OK response; is it 
>legal for user B to *still*  change SDP in the 2xx response 
>as the act of sending a 1xx response reliably and getting 
>acknowledgement completes the requirements for the 
>offer/answer model and there are no pending offers for which 
>B has not provided an answer ?

No. To my understanding the SDP in the 200 for the INVITE MUST be the same as the first SDP you received
reliably - even if there are additional offer/answer transactions before you receive 200 for the INVITE.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David R Oran | 1 Sep 2004 15:43
Picon
Favicon

Possible deficiency in rtcp-summary

A colleague pointed out to me that there appears to be no way to tell 
which RTP stream the report applies to.

The application/rtcp-xr mime definition contains the necessary goop to 
tie things back to the sip dialog 
(DialogID:38419823470834;to-tag=8472761;from-tag=9123dh311) but this 
seems insufficient to figure out exactly which RTP stats are being 
reported because:

a) The IP addresses for the media streams may be different from those 
used for the SIP dialog
b) there is no SSRC to cover various cases such as multicast
c) There is no SDP body part to use to correlate with the report
d) even if there were an SDP, there's no fid or other intra-session 
marker to figure out which stream is being reported on.

On the assumption I didn't miss something obvious and this in fact 
needs fixing, there are a few ways to do it.

1) We could put an SDP body into the publish as well, with either fid 
or some other marker so that the right m= line can be found. This would 
solve the addressing part but not the SSRC part.
2) We could put the session 5-tuple and SSRC into application/rtcp-xr
3) we could switch from an avp encoding to just sending a raw rtcp 
packet augmented with the addressing info.

I don't like 1. It's kludgy.

I'm ambivalent about 3, partly for the reasons that led folks to choose 
avp encoding, and partly because sending raw rtcp doesn't by itself
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkatesh Venkataramanan | 1 Sep 2004 18:59
Favicon

RE: Clarification regarding Offer/Answer Model

So, in case (1), per section 13.2.1 of RFC 3261, from a UAS's perspective in the absence of reliable 1xx
transmission : "the answer for the offer sent by it in the INVITE is only the SDP received by it in a 2xx
response". 

Doesn't this mean anything else received in a 1xx MUST be ignored by the UAS or rather has no significance
from the UAS's perspective?

Regarding (2), consider the following scenario:

1. A sends an INVITE with SDP1 to B.
2. B sends a 1xx response with SDP2 (reliable).
3. PRACK/200 OK.
4. User B sends a UAS sends an UPDATE with SDP3; acknowledged with a 200 OK by A.
5. If for the 200 OK for INVITE should the UAS sends SDP1 (from what you say below), where does A stream to?
SDP2? or SDP3?

Venkatesh.

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg <at> ericsson.com]
Sent: Wednesday, September 01, 2004 12:08 AM
To: Venkatesh Venkataramanan; sipping <at> ietf.org; jdrosen <at> dynamicsoft.com
Subject: RE: [Sipping] Clarification regarding Offer/Answer Model

Hi,

>I had a couple of questions regarding the Offer/Answer model. 
>Assume the following call flow:
> 
>1. User A sends INVITE with SDP to User B.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christer Holmberg (JO/LMF | 1 Sep 2004 19:20
Picon
Favicon

RE: Clarification regarding Offer/Answer Model


Hi,

>So, in case (1), per section 13.2.1 of RFC 3261, from a UAS's 
>perspective in the absence of reliable 1xx transmission : 
>"the answer for the offer sent by it in the INVITE is only 
>the SDP received by it in a 2xx response". 
> 
>Doesn't this mean anything else received in a 1xx MUST be 
>ignored by the UAS or rather has no significance from the 
>UAS's perspective?

Do you mean the UAC?

The UAC may use the SDP if received in a unreliable 18x, but since it's unreliable the UAS can not be sure the
UAC has received it (at least not if send on UDP).

>Regarding (2), consider the following scenario:
> 
>1. A sends an INVITE with SDP1 to B.
>2. B sends a 1xx response with SDP2 (reliable).
>3. PRACK/200 OK.
>4. User B sends a UAS sends an UPDATE with SDP3; acknowledged 
>with a 200 OK by A.
>5. If for the 200 OK for INVITE should the UAS sends SDP1 
>(from what you say below), where does A stream to? SDP2? or SDP3?

My understanding is that the 200 for INVITE should still contain SDP2, ie the FIRST answer sent by B. Of
course, that SDP really doesn't have any meaning anymore at that point, so I assume UAC will simply discard it...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Rosenberg | 2 Sep 2004 02:12

Re: Clarification regarding Offer/Answer Model


Christer Holmberg (JO/LMF) wrote:

> Hi,
> 
> 
>> So, in case (1), per section 13.2.1 of RFC 3261, from a UAS's 
>> perspective in the absence of reliable 1xx transmission : "the
>> answer for the offer sent by it in the INVITE is only the SDP
>> received by it in a 2xx response".
>> 
>> Doesn't this mean anything else received in a 1xx MUST be ignored
>> by the UAS or rather has no significance from the UAS's
>> perspective?
> 
> 
> Do you mean the UAC?
> 
> The UAC may use the SDP if received in a unreliable 18x, but since
> it's unreliable the UAS can not be sure the UAC has received it (at
> least not if send on UDP).

Right.

> 
> 
>> Regarding (2), consider the following scenario:
>> 
>> 1. A sends an INVITE with SDP1 to B. 2. B sends a 1xx response with
>> SDP2 (reliable). 3. PRACK/200 OK. 4. User B sends a UAS sends an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Venkatesh Venkataramanan | 2 Sep 2004 04:05
Favicon

RE: Clarification regarding Offer/Answer Model


-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg <at> ericsson.com]
Sent: Wednesday, September 01, 2004 10:20 AM
To: Venkatesh Venkataramanan; sipping <at> ietf.org; jdrosen <at> dynamicsoft.com
Subject: RE: [Sipping] Clarification regarding Offer/Answer Model

Hi,

>So, in case (1), per section 13.2.1 of RFC 3261, from a UAS's 
>perspective in the absence of reliable 1xx transmission : 
>"the answer for the offer sent by it in the INVITE is only 
>the SDP received by it in a 2xx response". 
> 
>Doesn't this mean anything else received in a 1xx MUST be 
>ignored by the UAS or rather has no significance from the 
>UAS's perspective?

Do you mean the UAC?

Yes ! 

The UAC may use the SDP if received in a unreliable 18x, but since it's unreliable the UAS can not be sure the
UAC has received it (at least not if send on UDP).

But my question is that, since the SDP in the 1xx response is not considered an 'answer', shouldn't the SDP in
the 2xx response received by the UAC override anything it received in the 1xx?

>Regarding (2), consider the following scenario:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
PTL Hsueh-Teng Liu | 2 Sep 2004 04:43
Picon

key exchange protocol for IPSec SIP-based VoIP system

Hi, all,

I'd like to discuss key exchange protocol that is integrated with session
control protocols such SIP for IPSec SIP-based VoIP system.

As you know, MIKEY is a key exchange protocol aimed to integrate with
session control protocols such SIP for SRTP. But, IPSec/IKE is also a
solution of choice to secure SIP/SDP signaling and RTP transmission.
However, on the assumption that a new IPSec SA is required for each call,
the serious problem of the IPSec/IKE enabled SIP-based VoIP system is that
the additional IKE key negotiations (one is for secure signaling and the
other is for secure RTP) will exacerbate the call setup time.

Therefore, I have questions about are there any tasks or published drafts
focus on proposing new or improving existing (IKE, IKEv2) key exchange
protocol which is integrated with session control protocols for IPSec
SIP-based VoIP system?

If you've already discussed this issue, please tell me the pointer for them.
Thank you in advance.

Howard Liu

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christer Holmberg (JO/LMF | 2 Sep 2004 08:01
Picon
Favicon

RE: Clarification regarding Offer/Answer Model


Hi,

>>So, in case (1), per section 13.2.1 of RFC 3261, from a UAS's 
>>perspective in the absence of reliable 1xx transmission : 
>>"the answer for the offer sent by it in the INVITE is only 
>>the SDP received by it in a 2xx response". 
>> 
>>Doesn't this mean anything else received in a 1xx MUST be 
>>ignored by the UAS or rather has no significance from the 
>>UAS's perspective?
> 
>Do you mean the UAC?
> 
>Yes ! 
> 
>The UAC may use the SDP if received in a unreliable 18x, but 
>since it's unreliable the UAS can not be sure the UAC has 
>received it (at least not if send on UDP).
> 
>But my question is that, since the SDP in the 1xx response is 
>not considered an 'answer', shouldn't the SDP in the 2xx 
>response received by the UAC override anything it received in the 1xx?

Yes, it should. So, if someone for whatever reason send different SDPs in unreliable 18x responses and the
200 (it's against the protocol to do so, though) the SDP in the 200 should "override" whatever was received before.

Regards,

Christer
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christer Holmberg (JO/LMF | 2 Sep 2004 08:04
Picon
Favicon

RE: Clarification regarding Offer/Answer Model


Hi,

>>>1. A sends an INVITE with SDP1 to B. 2. B sends a 1xx response with
>>>SDP2 (reliable). 3. PRACK/200 OK. 4. User B sends a UAS sends an
>>>UPDATE with SDP3; acknowledged with a 200 OK by A. 5. If for the
>>>200 OK for INVITE should the UAS sends SDP1 (from what you say
>>>below), where does A stream to? SDP2? or SDP3? 
>>My understanding is that the 200 for INVITE should still contain
>>SDP2, ie the FIRST answer sent by B. Of course, that SDP really
>>doesn't have any meaning anymore at that point, so I assume UAC will
>>simply discard it...
>Actually the 2xx to the original INVITE should not have an 
>SDP at all. 
>The o/a exchanges have been completed. Including one would introduce 
>exactly the uncertainty you are worried about - it would make 
>it unclear what the current SDP is.

I agree, and I don't have anything against NOT including an SDP in the 200 for this case.

However, a long time ago I think there was a discussion about this, and at that point it was said that the SDP
should be in the 200 for "backward compability".... or something like that. However, I am more than happy
if I remember wrong :)

Regards,

Christer

> 
> -Jonathan R.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jari Arkko | 2 Sep 2004 12:03

Re: key exchange protocol for IPSec SIP-based VoIP system

PTL Hsueh-Teng Liu wrote:
> Hi, all,
> 
> I'd like to discuss key exchange protocol that is integrated with session
> control protocols such SIP for IPSec SIP-based VoIP system.
> 
> As you know, MIKEY is a key exchange protocol aimed to integrate with
> session control protocols such SIP for SRTP. But, IPSec/IKE is also a
> solution of choice to secure SIP/SDP signaling and RTP transmission.
> However, on the assumption that a new IPSec SA is required for each call,
> the serious problem of the IPSec/IKE enabled SIP-based VoIP system is that
> the additional IKE key negotiations (one is for secure signaling and the
> other is for secure RTP) will exacerbate the call setup time.
> 
> Therefore, I have questions about are there any tasks or published drafts
> focus on proposing new or improving existing (IKE, IKEv2) key exchange
> protocol which is integrated with session control protocols for IPSec
> SIP-based VoIP system?

In theory you could define new MIKEY parameters to enable it
to negotiate other protocols than SRTP (Section 6.10, RFC 3830).

But I'm not 100% convinced that an IPsec capability would be needed.
I would see IPsec being used in a case where all traffic between the
two parties is protected by anyway by the same SA. If you want very
fine grained SAs, you may end up in trouble. For instance, I'm not
sure how port numbers and selectors would be handled. In case SRTP
would probably perform better in such situations.

(Also, you are likely to need new SAs for each call anyway,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane