Hi Murali, I came across a draft "draft-mule-sip-t38callflows-02.txt", which (section 6.2)has an example of fallback to G711 fax pass-through in case of an unsuccessful fax call. Here the fax offer contains T-38. If the other party doesnt support T-38 then a new offer is made with G711 for fax pass-through.
I am not sure if this how we need to handle the fax calls as the draft has expired. Regards, Sachin > Hi, > > I have a similar query regarding the changing of media streams. Do let > me know if this is a valid sequence > > Initial 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 5000 RTP/AVP 4 18 0 8 m=image > 7000 udptl t38 a=(other a= fileds would follow) > > Answer: > v=0 > o=bob 1890844526 1890844526 IN IP4 host.biloxi.example.com > s= > c=IN IP4 host.biloxi.example.com > t=0 0 > m=audio 5000 RTP/AVP 0 8 > m=image 0 udptl t38 > > On detecting DIS(offer for switching over to fax): > 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 0 RTP/AVP 4 18 0 8 m=image > 7000 udptl t38 a=(other a= fileds would follow) m=audio 5000 RTP/AVP 0 8 > /*Line added to support fax pass-through if the other end does not > support t38*/ > > Answer(For switching over to fax): > v=0 > o=bob 1890844526 1890844527 IN IP4 host.biloxi.example.com > s= > c=IN IP4 host.biloxi.example.com > t=0 0 > m=audio 0 RTP/AVP 4 18 0 8 > m=image 7000 udptl t38 > a=(other a= fileds would follow) > m=audio 0 RTP/AVP 0 8 > > On detecting the end of fax(if switching to voice is required): v=0 > o=alice 2890844526 2890844528 IN IP4 host.atlanta.example.com s= c=IN > IP4 host.atlanta.example.com t=0 0 m=audio 5000 RTP/AVP 4 18 0 8 m=image > 0 udptl t38 a=(other a= fileds would follow) m=audio 0 RTP/AVP 0 8 > > Answer for switching to Voice: > v=0 > o=bob 1890844526 1890844528 IN IP4 host.biloxi.example.com > s= > c=IN IP4 host.biloxi.example.com > t=0 0 > m=audio 5000 RTP/AVP 0 8 > m=image 0 udptl t38 > m=audio 0 RTP/AVP 0 8 > > Also suggest SIP real time fax call flow drafts which are RFC 3264 > compliant. > > Regards, > Murali > > Paul Kyzivat <[EMAIL PROTECTED]> wrote: > There has been an evolution of thinking on this subject. Originally > (2543 I guess) once a media line had been offered, that particular > "slot" in the SDP was taken, and could only be used for the same kind of > > media. If it was once refused (with a port=0) it could never be used > again. > > Later, it was concluded that once the slot had been rendered inactive > with port=0, it could subsequently be reused. And then it was recognized > > that if that was ok, then it might as well be possible for a new offer > to totally change a "slot" in the SDP to an entirely different media > type/transport, etc. > > It still should be the case that the replacement media stream be somehow > > logically a replacement for the prior one. > > Whay you suggest, switching from RTP/AVP to RTP/SAVP seem entirely > reasonable. Of course, if you do this, you must be prepared for it to > fail. This could fail in a couple of ways: > > - the reinvite itself could fail. If so, the prior media streams must > remain in effect > > - the reinvite could succeed, but the media stream in the new offer > could be rejected (port=0 in the answer). In that case you still have a > call, but the old media stream is gone and there is nothing to replace > it. > > Paul > > [EMAIL PROTECTED] wrote: > > Chiatali, > > My undertsanding of the section in 3264 you are querying is that > > if you offered two m= lines in the original request you need to offer > at > > least that in the new request and that the ordering of them is > preserved, > > new media offered should be appended to the previous SDP. So if you > > offered audio m= and video m= then you these should be in the new > request. > > So you m line for audio is still there, you might just be adding > another > > codec to it, or you may be setting one of them inactive. I hope I am > right > > ! and I hope the above makes sense. > > > > Regards - Wayne D. > > > > > > Chiatali asked --> > > ***************************** > > Hi Wayne, > > > > But what does the below statement from RFC 3264 means > > > > " If an SDP is offered, which is different from the previous SDP, the > > new SDP MUST have a matching media stream for each media stream in the > > > previous SDP. The i-th media stream in the previous SDP, counting from > > > the top,matches the i-th media stream in the new SDP, counting from > > the top." > > > > Is it not that if the 1st media stream in previous offer has RTP as > > the > > protocol then in the Subsequent offers sent the 1st stream must also > use > > RTP as transport. > > > > what does matching the media stream mean..? > > > > Thanks, > > Chaitali > > > > > > [EMAIL PROTECTED] wrote: > > > > Chaitali, > > If support for it has been indicated in the signalling from the > > UAS (UPDATE listed in the Allow header), the UAC can change the SDP by > > > sending an UPDATE request (RFC3311), in early or comfirmed dialog - as > in > > your example below. Or complete the initial INVITE request and then > > re-INVITE the UAS with the desired SDP. > > > > Regards - Wayne D. > > > > > > ********************************************************** > > Chaitali asked -> > > > > Hi All, > > I need some clarifications regd Offer Answer Model.User A sends Invite > > > to > > UserB with RTP as transport and B accepts the call with 200 > > User A SDP: > > 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 8 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > > > and B replies with > > 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 0 8 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > > > > > Can B Send an Updated Offer changing the Transport Is this valid ? 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/SAVP 0 8 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:8 PCMA/8000 > > > > Thanks, > > Chaitali > > > > > > > > --------------------------------- > > Do you Yahoo!? > > Yahoo! Search presents - Jib Jab's 'Second Term' > > _______________________________________________ > > Sip-implementors mailing list [email protected] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > ********************************************************************** > > ******** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > > This message is confidential, and may contain proprietary or legally > > privileged information. If you have received this email in error, > please > > notify the sender and delete it immediately. > > > > Internet communications are not secure. You should scan this message > > and > > any attachments for viruses. Under no circumstances do we accept > liability > > for any loss or damage which may result from your receipt of this > message > > or any attachments. > > > ************************************************************************ > ****** > > Do you Yahoo!? > > Yahoo! Search presents - Jib Jab's 'Second Term' > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > --------------------------------- > Do you Yahoo!? > Yahoo! Mail - now with 250MB free storage. Learn more. > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
