I am facing one problem in my network for audio conferencing call.
Audio conferencing platform is sending the 1st INVITE message to the
called party of softswitch.The call flow is as below.
Audioconf. Audioconf. Softswitch
Media sever Application server
sender receiver
INVITE (1)-----No
SDP------------->
<----------------------- 100
<----------------------- 180
PRACK
------------------->
<----------------------- 200
INVITE < ------------------------------
100 ----------------------------------->
200 --------------sdp----------------------->
ACK
------------------->
INVITE (2) -----
SDP--------------> for the same session
<------------------------------ 100
Softswitch is not sending 200 ok , as softswich is getting ACK of 1st
INVITE after 2nd INVITE. and ignoring 2nd INVITE
However in ethereal trace Audo confernce is sending ACK before 2nd INVITE
but through IP core it is reaching after INVITE in softswich .
Thats why softswitch is not sending 200 OK
How to resolve this
With best regards
Md. Faruk Apel Chowdhury
AE/NGN/NMC-SE
Ext: 85-2538
Mob: 050-4442101
----- Forwarded by Md Faruk Apel Chowdhury/ENG/HOAUH/ETISALAT/AE on
06/02/2008 02:33 PM -----
Sree <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/02/2008 02:31 PM
To
Iñaki Baz Castillo <[EMAIL PROTECTED]>
cc
[email protected]
Subject
Re: [Sip-implementors] Question on matching response to a transaction
Hi Inaki,
Thanks for the quick reply.
I was actually referring to the matching of *Responses* to a client
transaction, while your reply relates to matching of *Requests* to a
transaction
Any help in this matter is highly appreciated.
Thanks and Regards,
Sree
Iñaki Baz Castillo wrote:
> El Monday 02 June 2008 10:50:43 Sree escribió:
>
>> Hi,
>>
>> According to section 17.1.3 "Matching Responses to Client
Transactions",
>> only the Via branch and the CSeq method are considered for matching a
>> response to a Request.
>>
>> In such a scenario, what is the action to be taken on Response that
contain
>> the Via branch and Cseq method identical to the Request that created
the
>> transaction, but differs in either/all of the following headers:
>> From: [differs in from-URI only] and/or From: [differs in from-tag]
>> To: [differs in to-URI only] and/or To: [differs in to-tag]
>> Call-ID:
>>
>
> The request is first inspected by the transport layer, later by the
> transaction layer and finally by the core.
>
> During the transaction layer inspection you mus perform the steps in
17.1.3
> and if they match them the request is a retransmission and the
transaction
> layer MUST reply the last response received fro mthe core. Just it.
>
> If the request is not a retransmission then it coul be forwarded to the
core
> and it could inspect the To/From tags to match a dialog if it wants.
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
-----------------------------------------
The content of this email together with any attachments, statements
and opinions expressed herein contains information that is private
and confidential, are intended for the named addressee/s only. If
you are not the addressee of this email you may not copy, forward,
disclose or otherwise use it or any part of it in any form
whatsoever. If you have received this message in error, please
notify [EMAIL PROTECTED] by email immediately and delete the
message without making any copies.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
