[SIPForum-discussion] rport in via header

[narasimham.settipalli at wipro.com]

Hi,

 

Call Hold can be indicated through a parameter in SDP. RFC3264 has
recommendation as how to implement it. 

8.4 Putting a Unicast Media Stream on Hold
 
   If a party in a call wants to put the other party "on hold", i.e.,
   request that it temporarily stops sending one or more unicast media
   streams, a party offers the other an updated SDP.
 
   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.
 

 

By adding zero port in m line either indicates media capabilities of the
user or passivating the media stream. 

 

Rgds,

Narasimham.

 

________________________________

From: discussion-bounces at sipforum.org
[mailto:discussion-bounces at sipforum.org] On Behalf Of darshan b n
Sent: Tuesday, February 16, 2010 12:36 PM
To: discussion at sipforum.org
Subject: Re: [SIPForum-discussion] rport in via header

 


Hi,

 

Can we put the call on HOLD using Re-INVITE with SDP m line mediaport
Zero

 

9 02162010 051853.00396:1.06.05703.Info    .NRM  :
*NrmCallEstablishedNfy(), GCID:50005 called by srcHandle:5003e
210 02162010 051853.00397:1.06.05704.Info    .SG   : OA-FSM:0 output
SIPSG callId 0x000a000b GCID:0x00050005 ingress SG_CONN_CONN_CONN event
OA_EV_NRMA_MODIFY_RPY state OA_NULL
216 02162010 051853.00398:1.06.05705.Info    .SG   : Out(1):SG FSM,
SG:SIPSG,SgId:0x000A000B,GCID:0x00050005,Ev:SG_EV_NRMA_MSG,Old
State:SG_CONN_CONN_CONN,New State:SG_CONN_CONN_CONN
246 02162010 051853.00399:1.06.05706.Info    .CC   : CC FSM :
CcId:0x00060005,GCID:0x00050005,ACCT CALL ID:0x00000007,
event:CC_EV_NRMA_RES_STATE_UPDATE_NFY,old state:CC_CONN_CONN_CONN,new
state:CC_CONN_CONN_CONN
226 02162010 051853.00400:1.06.05707.Info    .NRMA :
*NrmaSendNrmCallUpdateNfy: gcid=0x50005 nfyType=0x10f origHandle=0x5003e
postpone=0 isStable=1 wasStable=0 result=0x0 cpcln 4 hpcQueInf 0x0
202 02162010 051903.00001:1.01.01616.Info    .SIPFE: Receive Msg From:
10.34.15.175/5071, len: 585, sigPort: 1, socket: 3, INVITE
sip:41928568 at 10.34.15.172:5060 SIP/2.0
693 02162010 051903.00002:1.01.01617.Info    .SIPFE: SipFeSocketRecvMsg
- msg = INVITE sip:41928568 at 10.34.15.172:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.10.50:5071;branch=z9hG4bK-1-9
From: sipp <sip:41928569 at 172.16.10.50:5071>;tag=484SIPpTag001
To: sut <sip:41928568 at 10.34.15.172:5060>;tag=gK05800ab4
Call-ID: 1-484 at 172.16.10.50
CSeq: 2 INVITE
Contact: sip:sipp at 172.16.10.50:5071
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length:  181

v=0
o=user1 53655765 2353687638 IN IP4 172.16.10.50
s=-
c=IN IP 172.16.10.50
t=0 0
m=audio 0 RTP/AVP 0 8 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
, msgLen = 585.
301 02162010 051903.00003:1.01.01618.Info    .SIPFE: SipFeSocketRecvMsg
- msg = v=0
o=user1 53655765 2353687638 IN IP4 172.16.10.50
s=-
c=IN IP 172.16.10.50
t=0 0
m=audio 0 RTP/AVP 0 8 18
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
, msgLen = 172.
192 02162010 051903.00004:1.0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100217/56772029/attachment-0002.html>