Danail Kirov wrote:
> Thanks Paul,
> "(You cannot accurately construe that because you have been offered
> sendonly you must have been put on hold."
> That is the reason I would have expected to see a push for a standard
> HOLD event. Do you see anything like that happening in the near future,
> or things are going to stay exactly as they are?
I don't anticipate any action in ietf. It is out of scope of things
normally done. Before it could be done, there would have to be a clear
definition of what "hold" means. I think that is lacking. And without
reference to a user interface I doubt it is possible to define it.
What there is has some semantics that are similar to the commonly
understood meaning of hold - namely "I don't want to receive media from
you". What it doesn't say is *why*.
Having done some work on defining the reinterpretation of Telcordia
features on SIP, I am aware that some audiences are *very* picky about
what they mean by "hold".
Paul
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 16, 2006 5:03 PM
> To: Danail Kirov
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Discrepancy with RFC3264 call hold
> scenario and RFC4317
>
> I don't claim to be the one who chose this direction. But in reality
> there is nothing that is explicitly for hold. The directionality
> attributes are useful for many purposes. It happens that they are useful
>
> for hold as well. (You cannot accurately construe that because you have
> been offered sendonly you must have been put on hold.
>
> Another answer is that this was defined before the event mechanism was
> defined.
>
> Paul
>
> Danail Kirov wrote:
>
>>I am curios why the original SIP authors have chosen to use SDP
>>exchanges to indicate HOLD, instead of defining a "standard" event
>>package for HOLD?
>>Regards,
>>Danail
>>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED] On Behalf Of Paul
>>Kyzivat
>>Sent: Thursday, February 16, 2006 4:24 PM
>>To: Paul Kyzivat
>>Cc: [email protected]
>>Subject: Re: [Sip-implementors] Discrepancy with RFC3264 call hold
>>scenario and RFC4317
>>
>>Bill kindly pointed out to me that I didn't answer his question.
>>My revised response to him was:
>>
>>
>>
>>>Bill,
>>>
>>>Sorry. I didn't read your posting carefully and jumped to an improper
>>
>>conclusion about what you were saying.
>>
>>
>>>Yes, I agree with you that 4317 is in error.
>>
>>
>> Paul
>>
>>Paul Kyzivat wrote:
>>
>>
>>>Bill,
>>>
>>>There is a set of rules, which you quote, for what may be in an answer
>>
>>
>>>depending on what is in the offer. But that does not constrain what
>>
>>may
>>
>>
>>>be in a subsequent offer relative to the same stream. E.g.:
>>>
>>>0) A offers sendrecv, B answers sendrecv
>>>1) A offers sendonly, B answers recvonly
>>>2) B offers inactive, B answers inactive
>>>3) A offers sendrecv, B answers sendonly
>>>4) B offers sendrecv, A answers sendrecv
>>>
>>>In (0) a normal call is established. In (1) A puts the call on hold.
>>
>>In
>>
>>
>>>(2) B gets tired of waiting and also puts the call on hold. In (3) A
>>>tries to take the call off hold and finds out he has been held. In (4)
>>
>>B
>>
>>
>>>takes the call off hold so A and B can talk again.
>>>
>>>The trick is that each side keeps the state that it *wants* to be in.
>>
>>It
>>
>>
>>>puts that into offers. In answers it puts the min(what it wants, what
>>
>>it
>>
>>
>>>is permitted based on the offer).
>>>
>>> Paul
>>>
>>>Bill Moats wrote:
>>>
>>>
>>>
>>>>Hello all, I have been surfing your SIP forum for quite a while and
>>
>>have
>>
>>
>>>>found it extremely useful.
>>>>I hope that you can shed some light on my current call hold problem.
>>>>I have been implementing a SIP protocol stack using SDP and have run
>>
>>into
>>
>>
>>>>problems when dealing with a phone going on hold.
>>>>
>>>>RFC3264 Section 6.1 says:
>>>>"If a stream is offered as sendonly, the corresponding stream MUST be
>>
>>marked
>>
>>
>>>>as recvonly or inactive in the answer."
>>>>
>>>>RFC3264 Section 8.4 also says:
>>>>"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."
>>>>
>>>>In my mind, it seems to me that RFC3264 is very clear on how to deal
>>
>>with
>>
>>
>>>>ANY offer that is marked a=sendonly.
>>>>You can 1)set the port to 0 to reject the offer 2) respond with
>>
>>a=recvonly
>>
>>
>>>>3) respond with a=inactive.
>>>>You certainly can NOT respond to a sendonly stream with sendrecv!!!
>>>>
>>>>However, if my software responds to a=sendonly with a=recvonly the
>>
>>phone I
>>
>>
>>>>have will only continue to offer a=sendonly from that point on.
>>>>But then I read RFC4317 Section 3.2 which lists an example in which
>
> an
>
>>offer
>>
>>
>>>>a=sendonly is responded to with no direction attribute (which implies
>>>>sendrecv!). The section of interest is below:
>>>>
>>>>[Second-Offer]
>>>>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
>>>>
>>>>Is this not a violation of the statement from RFC3264 Section 8.4!!!!
>>
>>Or is
>>
>>
>>>>there some other mechanism to define why this happens?
>>>>Is this possibly an error in RFC4317? Is the phone I am using
>>
>>non-compliant?
>>
>>
>>>>Any assistance or advice you could give on the subject would be
>>
>>greatly
>>
>>
>>>>appreciated!
>>>>
>>>>Thanks in advance
>>>>
>>>>Bill
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>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
>>>
>>
>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
