Subject: RE: [Sipping] Question about call flow in draft-ietf-sipping-serv ice-examples-03

From: "Miao, Kai" <[email-masked]>
Date: Wed, 12 Feb 2003 07:38:03 -0700

Hi Ajit,
 
I had noticed in RFC 3264 (right after I sent my email):
 
   "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.

   .........

   Typically, when a user "presses" hold, the agent will generate an
   offer with all streams in the SDP indicating a direction of sendonly,
   and it will also locally mute, so that no media is sent to the far
   end, and no media is played out."

This should explains why the example was that way.........basically it
doesn't matter what the answer is because there is no stream sent from User
B...... 
 
But, my question is why not make things more consistent by using
"a=recvonly" (or "a=inactive") instead of the default "a=sendrecv" in the
answer? What happen if the case is not stream on hold, for example, if it is
changing a stream from "sendrecv" to "sendonly"? Wouldn't this type of
answer cause confusion and violate the "rules" stated in RFC3264?
 
Thanks,
Kai   

-----Original Message-----
From: Ajit Kalele [mailto:[email-masked]]
Sent: Wednesday, February 12, 2003 12:27 AM
To: Miao, Kai
Cc: [email-masked]
Subject: Re: [Sipping] Question about call flow in
draft-ietf-sipping-service-examples-03

Hi, 

I think there is an error in the call flows. 

Either A has to respond with an "a=inactive", so that there is no RTP flow
between the UAs, or else there should be unidirectional RTP flow between the
2 UAs. 

Best Regards 
- Ajit 

"Miao, Kai" wrote: 

 Could someone provide an answer to the following question:In the first
example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, why
F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, i.e.,
200 OK, has no "a=" attribute at all while "No RTP Sent!" is marked in the
call flow diagram? Shoudn't F12 contain a=recvonly or a=inactive, following
the Offer/Answer model? Why there is "no RTP sent" in the diagram when there
is "a=sendonly" in F10?Thanks,Kai MiaoIntel 

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

---

From: Alan Johnston <[email-masked]>
Date: Wed, 12 Feb 2003 09:18:26 -0600

Hi,

Thanks for the comments on the draft.

You are correct - the answer to the hold offer (a=sendonly) should be 
a=recvonly instead of what is currently shown as sendrecv in the draft.

This will be fixed in the next version of the document.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

At 07:38 AM 2/12/2003 -0700, Miao, Kai wrote:
>doesn't matter what the answer is because there is no stream sent from 
>User B......
>
>answer? What happen if the case is not stream on hold, for example, if it 
>is changing a stream from "sendrecv" to "sendonly"? Wouldn't this type of 
>between the UAs, or else there should be unidirectional RTP flow between 
>the 2 UAs.
>
>Best Regards
>- Ajit
>
>"Miao, Kai" wrote:
>> example, Call Hold, given in draft-ietf-sipping-service-examples-03.txt, 
>> why F10, i.e., INVITE(hold), has a=sendonly in its SDP message and F12, 
>> i.e., 200 OK, has no "a=" attribute at all while "No RTP Sent!" is 
>> marked in the call flow diagram? Shoudn't F12 contain a=recvonly or 
>> a=inactive, following the Offer/Answer model? Why there is "no RTP sent" 
>> in the diagram when there is "a=sendonly" in F10?Thanks,Kai MiaoIntel

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP