Subject: Re: [Sipping] A Test Balloon For AS generated Early Media: EMIND

From: "Siddhartha Bhakta" <[email-masked]>
Date: Tue, 21 Nov 2006 09:53:43 -0000

<<re-sending as it was exceeding mailing-list buffer>>
 
Hi,
 
If the objective of Application server model is to somehow de-multiplex
early media from regular media (in order to avoid media clipping) then
I think Brian's proposal is not going
beyond it. The RFC3959 has proposed one way to achieve Application Server
model whereas Brian is possibly proposing another way to achieve it.
 
The RFC3959 proposed Application server has the issue for NAT traversal
as specified below.
But the Brian's idea of discriminating early media from regular media based
on RTP payload type is showing a way to solve that problem quite
easily(specified
below).
 
NAT Traversal issue with Application Server model
-------------------------------------------------
There are NAT traversal devices that losses few initial media packet
before being able to exchange media. Not sure whether Interactive
Connectivity Establishment(ICE) also works on same principle or not.
However, RFC3959 proposed separate Media path (Source IP-Port, Dest
IP-port) for Early media and regular media. Atleast the UAC side should
have separate RTP IP/port for early media and regular media to be able
to discriminate regular media packet from early media packet.
Due to this, Media Pinhole for early media shall be different than
regular media. When regular media shall be established then few initial
regular media packet shall be lost for Media pinhole discovery.
This shall introduce media clipping for NATed case.

Solution
--------
If avoiding media clipping is the only objective then very simple call
flow can be proposed. Many SIP UA and B2BUA vendor may
find RFC3959 difficult to implement because it is creating multiple media
session for a dialog. Brian's proposal shall be simpler one but it is also
creating multiple media sessions even in non-forking case.
 
The UAC shall send INVITE with SDP offer containing two sets of payload
types
one for regular media and one for early media. The UAS's are allowed to
send 18x with early media payload type only in SDP. When they shall send
2xx they are allowed to send regular media payload type in SDP.
 
At UAC side, as soon as RTP packet with regular media payload type is
received it can mute all early media sessions. The Media pinhole shall
be created at the cost of few initial early media packets but that same
media pinhole shall be re-used for regular media also. Therefore, no
regular media packet shall be lost.

There are few ways to carry separate payload for early media
and regular media:
 
        1)Modifying the RTPMAP attributes to indicate whether a payload type
        is for early media or regular media whereas m= line shall carry
        regular media payload type and early media payload type.
        The existing RTPMAP syntax is,
    a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
     parameters>]
        It can be modified to,
    a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
     parameters>] [early]
        
         if optional 'early' flag is specified then that payload type shall
be
         for early media.
 
        v=0
        o=alice 2890844730 2890844731 IN IP4 host.example.com
        s=
        c=IN IP4 192.0.2.1
        t=0 0
        m=audio 20000 RTP/AVP 96 97
        a=rtpmap:96 PCMU/8000
        a=rtpmap:97 PCMU/8000 early
 
        In the above example, the 97 payload type is for early media.

        or
        2)Introduce early-media=line to carry early media payload types
under
        a media stream. The above example shall be modified to,

        v=0
        o=alice 2890844730 2890844731 IN IP4 host.example.com
        s=
        c=IN IP4 192.0.2.1
        t=0 0
        m=audio 20000 RTP/AVP 96
        early-media=97
        a=rtpmap:96 PCMU/8000
        a=rtpmap:97 PCMU/8000

 
Call Flow
-----------
      A                           B
      |                           |
      |--------(F1) INVITE------->|
      |            offer          |
      |                           |
      |<--(F2) Session Progress---|
      |       early-answer        |
      |                           |
      | ************************* |
      |        Early Media        |
      | <--------RTP for early media
      | <--------RTP for early media
      | ************************* |
      |                           |
      |<--------RTP for regular media
      |                           |
      |<--------(F3) 200 OK-------|
      |                           |
      |---------(F4) ACK--------->|
      |                           |

Where(Only format 1 is shown here),
F1:
   v=0
   o=alice 2890844730 2890844731 IN IP4 host.example.com
   s=
   c=IN IP4 192.0.2.1
   t=0 0
   m=audio 20000 RTP/AVP 96 97
   a=rtpmap:96 PCMU/8000
   a=rtpmap:97 PCMU/8000 early
 
F2:
   v=0
   o=Bob 2890844725 2890844725 IN IP4 host.example.org
   s=
   c=IN IP4 192.0.2.2
   t=0 0
   m=audio 30000 RTP/AVP 97
   a=rtpmap:97 PCMU/8000 early
 
F3:
   v=0
   o=Bob 2890844725 2890844725 IN IP4 host.example.org
   s=
   c=IN IP4 192.0.2.2
   t=0 0
   m=audio 30000 RTP/AVP 96
   a=rtpmap:96 PCMU/8000

Please check whether it makes sense or not.
 
Thanks,
Siddhartha

Paul wrote:
------------
 
Brian,

Is there a reason you propose something new like this in preference to the
Application Server model of early media specified in RFC 3960?

While apparently not implemented, it does have the advantage of having a
spec that is already done. Both it and what you propose present some
implementation/deployment challenges. Yours is probably somewhat simpler to
implement, but is that enough to be worth the trouble? If so, should we also
deprecate the application server model?

---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------

_______________________________________________
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