[SIPForum-discussion] Ring-back tone from calling side
Bourdoukis Dimitrios
dbourdoukis at hol.net
Tue Aug 12 13:28:51 UTC 2014
Hello
I understand that there is a SIP-I interface between the Class 5 and your softswitch. Normally in the PSTN world the B-side plays the RBT and therefore in this situation I would expect that the Class 5 should establish early media backwards for plying the RBT. If this is not the case, then the A-side should be able to play the RBT when no SDP body is present in the provisional response 18x. I your case I suppose the behind the soft-switch is a SIP client (subscriber A) taking SIP and therefore when this client receives 180 without SDP should play the RBT localy. If for some reason the soft-switch opens the early media backwards, then no-one will play the RBT.
Also, you may have a look at the informational RFC3960 for some more ideas.
--
Dimitris Bourdoukis
-----Original Message-----
From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of discussion-request at sipforum.org
Sent: Tuesday, August 05, 2014 8:24 PM
To: discussion at sipforum.org
Subject: discussion Digest, Vol 109, Issue 2
Send discussion mailing list submissions to
discussion at sipforum.org
To subscribe or unsubscribe via the World Wide Web, visit
http://sipforum.org/mailman/listinfo/discussion
or, via email, send a message with subject or body 'help' to
discussion-request at sipforum.org
You can reach the person managing the list at
discussion-owner at sipforum.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of discussion digest..."
Today's Topics:
1. routing of sip messages (mohit gupta)
2. Ring-back tone from calling side (Ramachandra moorthy)
3. # converted to %2 in SIP invite (Ramachandra moorthy)
4. Regarding require field in 183 Response (shuaib ahmad)
5. Wrong P-Asserted Identity in Subscribe Message to CSCF (Sunil P)
6. Re: Multiple 183 w/SDP along with PRACK (Stephen James)
----------------------------------------------------------------------
Message: 1
Date: Wed, 23 Jul 2014 12:32:56 +0530
From: mohit gupta <itismohit at gmail.com>
Subject: [SIPForum-discussion] routing of sip messages
To: discussion at sipforum.org
Message-ID:
<CADPVk=f+GDP0EK0KObhDc+SBdZcyyxtaVKWV0hKMHPD00-QgrA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Just wondering in what scenarios can ROUTE header and RECORD-ROUTE header come together in a sip message, if at all ?
Is there any other provision to change the route after it is set for a dialog ?
Regards,
Mohit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20140723/ece842e7/attachment-0001.html
------------------------------
Message: 2
Date: Thu, 17 Jul 2014 17:56:09 +0530
From: Ramachandra moorthy <ramcm.irtt at gmail.com>
Subject: [SIPForum-discussion] Ring-back tone from calling side
To: discussion at sipforum.org
Message-ID:
<CAK7kMDWfs4Wrh0oaoQkKtQcUNZ31Vtz_GS_JCP1TqYnHExXj4A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear All,
kindly clarify the below query
"A" subscriber making call to "B" subscriber.In this scenario who will provide ringback tone?
Recently one class-5 switch has been connected with our softswitch.We have created SIP node with our softswitch.
But class5 switch expecting ringback tone from us if we are trying to make call towards class-5 subscriber.
In SIP trace we found class-5 switch not sending SDP body in their 180-ringing message.
below is the 180-ringing message from class-5
Sequence NO.:21
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.190.26.142:5060;branch=z9hG4bK0de62d85.0
Record-Route: <sip:10.190.26.142:5060;lr>
Call-ID: 000010ea000077e5-0046-0792 at 10.190.26.142
From: "8212412345"<sip:8212412345 at 10.190.26.142
>;tag=0abe1a8e-00004b60000060ba
To: "08024441120"<sip:08024441120 at 10.190.26.142>;tag=qqoqsnho-CC-1003
CSeq: 4459 INVITE
Require: 100rel
Contact: <sip:10.191.54.22:5060;transport=udp>
Call-Info: <sip:08024441120 at 10.191.54.22:5060
;transport=udp;user=phone>;purpose=call-completion;m=NR
RSeq: 1
Content-Length: 4
Content-Type: application/isup;version=ITU-t92+
/*----------start isup message data----------
0000: 06 04 01 00
ACM----address-complete message
Mandatory parameter:
Backward call indicators::
Charge indicator:No indication
Called party status indicator: subscriber idle Called party category indicator: No indication End-to-end method indicator: No end-to-end method available Interworking indicator: Interworking encountered End-to-end information indicator: No end-to-end information available ISDN user part indicator: ISDN user part not used all the way Hold provided indicator: Hold not Request ISDN access indicator: Termination access non-ISDN Echo control device indicator: Incoming half echo control device not included SCCP method indication: No indication
Optional parameter:
*----------end isup message data--------
*Kindly clarify why called party expecting ring-back tone from calling
side.*
*With Regards *
*M. Ramachandramoorthy+91- 9600070877*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20140717/ba4f0e2e/attachment-0001.html
------------------------------
Message: 3
Date: Thu, 17 Jul 2014 17:59:54 +0530
From: Ramachandra moorthy <ramcm.irtt at gmail.com>
Subject: [SIPForum-discussion] # converted to %2 in SIP invite
To: discussion at sipforum.org
Message-ID:
<CAK7kMDUXN7fLvd7Hsx+Nz8GMToz1ui+6vQQjT-F=H8KLqE9FhA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear All,
Kindly clarify my another query pls..
SIP subscriber dialing" #" sympol...but it is transfer like "%2" in SIP invite message..Kindly clarify whether this is right or wrong.
Below is the invite message
Sequence NO.:1
INVITE sip:2%232008 at 10.191.59.22:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.190.32.102:5060;branch=z9hG4bK7d9501b5.0
To: "2%232008"<sip:2%232008 at 10.190.32.102>
From: "4023325578"<sip:4023325578 at 10.190.32.102
>;tag=0abe2066-000011b200006f84
Call-ID: 0000052c000049e9-0047-0791 at 10.190.32.102
CSeq: 6673 INVITE
Contact: <sip:4023325578 at 10.190.32.102:5060>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,REFER,NOTIFY,PRACK,UPDATE
P-Asserted-Identity: <sip:4023325578 at 10.190.32.102>
Max-Forwards: 9
Record-Route: <sip:10.190.32.102:5060;lr>
Supported: 100rel
User-Agent: ZTE Softswitch/1.0.0
P-Charging-Vector: icid-value=Hyder-20140717125720-0001eb81
Content-Type: multipart/mixed;boundary=zte-unique-boundary-06
Content-Length: 515
--zte-unique-boundary-06
Content-Type: application/SDP
v=0
o=ZTE 4 27240 IN IP4 10.190.32.102
s=phone-call
c=IN IP4 10.190.32.22
t=0 0
m=audio 19658 RTP/AVP 8 18 97
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-11
a=ptime:20
--zte-unique-boundary-06
Content-Type: application/ISUP; base=nxv3; version=itu-t92+
Content-Disposition: signal; handling=optional
/*----------start isup message data----------
0000: 01 00 60 00 0a 03 02 07 05 01 90 c2 02 80 3d 01
0010: 1e 0a 07 03 13 04 32 23 55 87 c6 07 00 00 01 59
0020: 00 00 00 31 02 00 00 78 18 e2 82 c0 01 a1 12 02
0030: 01 00 02 01 01 30 0a 83 01 00 87 01 10 a9 02 84
0040: 00 78 21 81 80 c0 02 81 1c 1a 91 aa 06 80 01 00
0050: 82 01 00 8b 01 00 a1 0c 02 02 40 67 06 04 2b 0c
0060: 09 00 84 00 39 08 31 c0 c6 d0 3d c0 78 c4 00 IAM----Initial address message
Mandatory parameter:
Nature of connection indicators:
Satellite indicator:0 satellite circuits in the connection Continuity check indicator:Continuity check not required Echo control device indicator:Not Include
Forward call indicators:
International/national call indicator:national call End-to-end method indicator: Not available Interworking indicator: Interworking not encountered End-to-end information indicator: Not available ISDN user part indicator: ISDN user part used all the way ISDN user part preference indicator: ISDN user part not required all the way ISDN access indicator: Originating access non-ISDN SCCP method indication: No indication Collect Call:0
Calling party category:Ordinary subscriber Transmission medium requirement:3.1 kHz audio
Called party number:
Nature of address: subscriber number
Internal network number indicator (INN): *routing to internal network
number not allowed
Numbering plan indicator: ISDN numbering plan Address signal: 2#2008
Optional parameter:
Hop counter: 30
Calling party number:
Nature of address: National (significant) number
Calling party number incomplete indicator (NI): *Complete
Numbering plan indicator: ISDN numbering plan Address presentation restricted indicator: Presentation allowed Screening indicators: Network provided Address signal: 4023325578 Propagation delay counter: 0 ms Parameter compatibility Information:
Parameter#1
Propagation delay counter:
Transit at intermediate exchange indicator: Transit interpretation Release call indicator: Not release call Send notification: Not Send notification Discard message indicator: Not Discard message Discard parameter indicator:do not discard parameter (pass on) Pass on not possible indicator:discard parameter
*----------end isup message data----------*/
--zte-unique-boundary-06--
*With Regards M. RamachandramoorthyNGN-BSNL+91- 9600070877*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20140717/84d3e0a2/attachment-0001.html
------------------------------
Message: 4
Date: Fri, 18 Jul 2014 18:25:35 +0530
From: shuaib ahmad <shuaib.pantnagar at gmail.com>
Subject: [SIPForum-discussion] Regarding require field in 183 Response
To: discussion at sipforum.org
Message-ID:
<CAEqGPt3Psqbe5j99uYHGXpefA6doRegTv=iGaeUUBYUsjRLQmg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am new for SIP.
I have doubt. if UAC does not send require i.e. PRACK message in 183 response from UAS , UAS will progess normally or there will be some impact ?
--
Thanks and Regards
Shuaib Ahmad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20140718/e50c38d3/attachment-0001.html
------------------------------
Message: 5
Date: Mon, 21 Jul 2014 00:02:29 +0530
From: Sunil P <sunil.sipuser at gmail.com>
Subject: [SIPForum-discussion] Wrong P-Asserted Identity in Subscribe
Message to CSCF
To: discussion at sipforum.org
Message-ID:
<CAHffFazEJ+yqpJQj+qYUzea=2etx7Wq+XgzU5_Uwhq2MAps2og at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
What should be the behavior of CSCF if it receives Subscribe request from UE with wrong P-Asserted Identity header?.
Thanks and Regards,
Sunil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/discussion/attachments/20140721/5140227b/attachment.html
------------------------------
Message: 6
Date: Wed, 16 Jul 2014 17:47:24 -0500
From: Stephen James <sjames_1958 at yahoo.com>
Subject: Re: [SIPForum-discussion] Multiple 183 w/SDP along with PRACK
To: NK <nitinkapoorr at gmail.com>
Cc: discussion <discussion at sipforum.org>
Message-ID: <EF50A8E0-F0F8-44B9-BD4C-14E261E8E19D at yahoo.com>
Content-Type: text/plain; charset=us-ascii
This is perfectly valid, but not very useful. There may be a PSTN interconnect down the line that is sending multiple call progress messages resulting in the behavior that you see.
Sent from my iPad
> On Jul 9, 2014, at 5:01 PM, NK <nitinkapoorr at gmail.com> wrote:
>
> Dear All,
>
> I have call flow like where Vendor sends 183 w/SDP included Rseq and customer sents the PRACK and 200 OK from vendor.
>
> After that vendor is again sending 1~2 183 w/SDP where it is not changing anything in SDP but only asking for PRACK by sending RSEQ. I checked the RFC , but cannot see anything like which says UAS cannot send multiple 183 w/SDP.
>
> Can you please help on this, whether any UAS can send multiple 183 w/SDP where it is asking for PRACK? Is it valid call flow, because i cannot see anything RFC.
>
> Regards,
> Nitin Kapoor
> _______________________________________________
> This is the SIP Forum discussion mailing list TO UNSUBSCRIBE, or edit
> your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
------------------------------
_______________________________________________
This is the SIP Forum discussion mailing list TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org
End of discussion Digest, Vol 109, Issue 2
******************************************
More information about the discussion
mailing list