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
