Subject: [MMUSIC] help - question on SDP negotiation based on RFC 3264

From: [email-masked]
Date: Fri, 26 Jan 2007 17:46:23 +0100

I have 2 specific questions about the SDP media negotiation : I am not sure
to have a clear interpretation on some specific paragraph of the RFC 3264,
which describes the media renegotiation and the "on-hold" procedure....
Thanks in advance for your help.

Question #1

The RFC 3264 specifies §6.1 :

   If a stream is offered as sendonly, the corresponding stream MUST be
   marked as recvonly or inactive in the answer.  If a media stream is
   listed as recvonly in the offer, the answer MUST be marked as
   sendonly or inactive in the answer.  If an offered media stream is
   listed as sendrecv (or if there is no direction attribute at the
   media or session level, in which case the stream is sendrecv by
   default), the corresponding stream in the answer MAY be marked as
   sendonly, recvonly, sendrecv, or inactive.  If an offered media
   stream is listed as inactive, it MUST be marked as inactive in the
   answer.

The RFC 3264 specifies §8.4 :
Putting a Unicast Media Stream on Hold

   If a party in a call wants to put the other party "on hold", i.e.,
   request that it temporarily stops sending one or more unicast media
   streams, a party offers the other an updated SDP.

   If the stream to be placed on hold was previously a sendrecv media
   stream, it is placed on hold by marking it as sendonly.  If the
   stream to be placed on hold was previously a recvonly media stream,
   it is placed on hold by marking it inactive.

   This means that a stream is placed "on hold" separately in each
   direction.  Each stream is placed "on hold" independently.  The
   recipient of an offer for a stream on-hold SHOULD NOT automatically
   return an answer with the corresponding stream on hold.  An SDP with
   all streams "on hold" is referred to as held SDP.

Taking into account the follwoing basic scenario, where A user calls B
user, and where a SIP session is successfully  established. Then, A user
chooses to put B on-hold, and sends a new offer with all the media set to
'inactive'. B users generates his answer :

-> Based on §6.1(RFC 3264), Ithink that B user MUST generate an answer with
all the media set to inactive,
-> Based on §8.4, Isuppose that B CAN generate an answer without all the
media set to inactive.

What should be the right behaviour for B when generating his offer?

Question #2

Moreover, the examples given in the RFC 4317 (§3.2 listed below) seem to
show that an answer following a consecutive offer putting a stream on hold
can be constructed with identical SDP to the previous offer/answer
exchanged. Is it really possible as it does not seem to be consistent with
the RFC 3264? Can you please clarifies Alice's behaviour below?

Hold with Two Streams

   In this example, two audio streams have been established in the first
   offer/answer exchange.  In this second offer/answer exchange, one of
   the audio streams is placed on hold.  Alice offers two media streams,
   a bidirectional audio stream and a send-only telephone event stream.
   Bob accepts both streams.  Bob then puts Alice's audio stream on hold
   but not the tone stream.  Alice responds with identical SDP to the
   initial offer.

    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 0 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:97 iLBC/8000
      m=audio 49172 RTP/AVP 98
      a=rtpmap:98 telephone-event/8000
      a=sendonly

    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49172 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=audio 49174 RTP/AVP 98
      a=rtpmap:98 telephone-event/8000
      a=recvonly

    [Second-Offer] (From Bob)

      v=0
      o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
      s=      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49172 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      a=sendonly
      m=audio 49174 RTP/AVP 98
      a=rtpmap:98 telephone-event/8000
      a=recvonly

    [Second-Answer]

      v=0
      o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
      s=      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 0 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:97 iLBC/8000
      m=audio 49172 RTP/AVP 98
      a=rtpmap:98 telephone-event/8000
      a=sendonly

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Jan 2007 18:53:02 -0500

Annie,

comments inline.

[Alan - please not. Do you agree this is a bug in 4317?]

	Thanks,
	Paul

> What should be the right behaviour for B when generating his offer?

B must answer with inactive.

I'm not especially happy with how this was described in the rfc, but it 
has been discussed ad nauseum elsewhere. The use of sendonly to signify 
HOLD assumes that the holder still wants to transmit (presumably MOH). 
But often that is not the case. A holder that doesn't want to send 
anything should be able to offer inactive.

The answer to that must still be inactive - it is in effect an 
acknowledgment that it was understood.

BUT, that doesn't mean the B *wants* hold, only that it accepts it. If B 
subsequently generates a new offer, it can *offer* whatever it *wants*, 
which typically will be sendonly. Then if A still wants to be on hold 
(probably yes), then it can respond with inactive or sendonly.

> the RFC 3264? Can you please clarifies Alice's behaviour below?

I hadn't noticed this before. I believe the example is in error. The 
second answer is incorrect. The first stream in the second answer should 
be either recvonly or inactive.

Looks like a bug to me. Copying the author of that rfc.

	Paul

>       s=      t=0 0
>       s=      t=0 0
>       s=      t=0 0
>       s=      t=0 0

---

From: Alan Johnston <[email-masked]>
Date: Sun, 28 Jan 2007 15:27:59 -0600

I agree that the second offer/answer exchange in 3.2 of RFC 4317 appears 
to be wrong.   I can't recall right now what we were trying to show in 
it. I'm adding Robert in case he recalls the purpose of the scenario.   
The text says that the answer has the same SDP as the initial offer, yet 
the version is incremented.  I think it should be:

      v=0
      s=

    [Second-Answer]

      v=0
      s=     
      m=audio 49170 RTP/AVP 97

Thanks,
Alan

Paul Kyzivat wrote:
> I'm not especially happy with how this was described in the rfc, but 
> it has been discussed ad nauseum elsewhere. The use of sendonly to 
> signify HOLD assumes that the holder still wants to transmit 
> (presumably MOH). But often that is not the case. A holder that 
> doesn't want to send anything should be able to offer inactive.
>
> BUT, that doesn't mean the B *wants* hold, only that it accepts it. If 
> B subsequently generates a new offer, it can *offer* whatever it 
> *wants*, which typically will be sendonly. Then if A still wants to be 
> on hold (probably yes), then it can respond with inactive or sendonly.
>
>> Question #2
>>
> second answer is incorrect. The first stream in the second answer 
> should be either recvonly or inactive.
>