Hi Kumar,
Your understanding is correct. The new SDP in Re-INVITE is violating RFC 3264.
As per it, any new streams must be added below the previous ones or by reusing
the "slot".
Check the excerpt from RFC 3264:-
8.1 Adding a Media Stream
New media streams are created by new additional media descriptions
below the existing ones, or by reusing the "slot" used by an old
media stream which had been disabled by setting its port to zero.
Rosenberg & Schulzrinne Standards Track [Page 13]
?
RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
Reusing its slot means that the new media description replaces the
old one, but retains its positioning relative to other media
descriptions in the SDP. New media descriptions MUST appear below
any existing media sections. The rules for formatting these media
descriptions are identical to those described in Section 5.
So, it by no means, T.38 stream is added above audio stream. Moreover, the port
in audio should be 0. If UAS rejects the T.38 stream, then UAC should fallback
on Audio stream and try to establish fax on G.711 with T.38 stream port=0 and
audio stream =valid value.
Hope it helps.
regards,
Aman Aggarwal
Aricent
________________________________________
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
kumar.ramad...@wipro.com [kumar.ramad...@wipro.com]
Sent: Thursday, May 10, 2012 10:07 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] M line ordering in Re-invite SDP for Inter domain
fax call
Hi *,
For the inter domain fax call (for a SIP <-> PSTN call), after the basic call
setup, in case of fax tone detection at the Media Gateway, a new offer SDP
shall be sent to the remote party using Re-invite. This new offer SDP should
abide by the rules defined in RFC 3264. This SDP normally contains a media
description for "image", and additionally a media description for "audio",
which shall be used as a fallback (using voice band data).
The ordering of the media lines in the offer SDP should be in accordance with
Section 8 & 8.1 of RFC 3261, by which the new media line (in this case for
"image" media type) should be added at the end or should replace any m-line
which has been negated before using "port value" as "0".
So, our assumption is that, even though the "image" media type is after the
"audio" media type, T.38 shall still be considered first for the fax transfer,
and in case, if T38 fax is not supported, fallback using G.711 shall be used.
So, the query would be, whether there is a preference for the media line
ordering. For eg, if the "audio" media type is present before the "image" media
line, then I presume, there is no preference handling for "audio", as it is
present before "image" media type.
Please find below the typical T.38 fax scenario:
| GW1 Softswitch1 Softswitch 2 GW2
|
| | | | |
|
| |F1 NOTIFY{offhook}| | |
|
| |----------------->| | |
|
| |F2 NOTIFY{digit} | | |
|
| |----------------->| | |
|
| | F3 Add | | |
|
| |<---------------- | | |
|
| | | F4 INVITE | |
|
| | |---------------->| |
|
| | | F5 100 Trying | F6 Add |
|
| | |<----------------|------------->|
|
| | | | F7 Modify{ri}|
|
| | | |------------->|
|
| | | F8 180 Ringing| |
|
| | F9 Modify{rt} |<----------------| |
|
| |<-----------------| | F10Notify{of}|hookoff
|
| | | |<-------------|
|
| | | | F11 Modify |
|
| | | |------------->|
|
| | | F12 200 OK | |
|
| | |<----------------| |
|
| | F13 Modify | | |
|
| |<-----------------| F14 ACK | |
|
| | |---------------->| |
|
| | | | |
|
| | | | |
|
| | Both Way RTP Media Established |
|
| Fax |<=================================================>|
|
| ------>| | |
|
| emitted| | | |Preamb
|
| | | |F15Notify{V21}|<-----
|
| | | |<-------------|detctd
|
| | | F17 Re-INVITE | F16 Modify |
|
| | | (GW2 T38 SDP) |------------->|
|
| | F18 Modify |<----------------| |
|
| |<-----------------| | |
|
| | | F19 200 OK | |
|
| | |(GW1 T38 SDP) | |
|
| | |---------------->| |
|
| | | | F20 Modify |
|
| | | |------------->|
|
| | | F21 ACK | |
|
| | |<----------------| |
|
| | | |
|
| | T.38/UDPT Fax Flow Established |
|
| |<=================================================>|
|
| | | | |
|
| | | | |End of fax
|
| | | | |<---------
|
| End of | | | F22 Notify | detected
|
| fax | | F23 Re-INVITE |<-------------|
|
| detected | (GW2 voice SDP)| |
|
| ------>| |<----------------| |
|
| | F24 Notify | | |
|
| |----------------->| | |
|
| | F25 Modify | | |
|
| |<-----------------| | |
|
| | | F27 200 OK | |
|
| | | (GW1 voice SDP)| |
|
| | |---------------->| |
|
| | | | F28 Modify |
|
| | |<----------------| |
|
| | | | |
|
| | | | |
|
| | Both Way RTP Media Re-Established |
|
| |<=================================================>|
|
Following shall be the SDP present in the Re-invite after fax detection:
v=0
o=- 200804293 1328781680 IN IP4 192.168.13.235
s=SDP Data
c=IN IP4 192.168.13.235
t=0 0
m=image 51846 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=ecan:fb on -
m=audio 49846 RTP/AVP 8
a=ptime:10
a=ecan:fb on -
To my understanding of RFC 3264, the above SDP is not in-line with Section 8 &
8.1, if the previously offered or answered SDP (exchanged during the basic call
setup) contains only "audio" media type with same port number. Or is it still
OK to send the "image" media line before the "audio" media line for the fax
call scenarios?
Experts, I kindly request you to provide your views/comments in this regard. If
any further additional information is required, please let me know.
Thanks in advance,
kumar
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not the
intended recipient, you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately and destroy all copies of this message and
any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
