[SR-Users] R: Re: R: Re: RTPPROXY & BRANCH

[Marino Mileti]

The problem isn't on 183s but on the multiple INVITE that Kamailio sends to
clients behind rtpengine. Rtpengine open new ports for answer but on INVITE
the rtpengine ports are the same...This happens because for all these
clients the callid is still the same..so for rtpengine there's no
difference...for this reason I can see early media only on one of the
receivers

I've tried the "b" option...but in rtpengine "via-branch" is not managed
(it's commented on the source code). So I've tried some other things ..ad
example I've modified rtpengine in order to use via-branch instead
callid...and in this way everything works good :) but there are some other
issue because in every "rtpengine command" should be made some changes to
support this :) 

Now my idea is...if I leave rtpengine without any modify and change
rptproxy-ng module in order to modify callid (appending for example via or
some other parameters in order to make it unique) should it work?


-----Messaggio originale-----
Da: sr-users-bounces at lists.sip-router.org
[mailto:sr-users-bounces at lists.sip-router.org] Per conto di Richard Fuchs
Inviato: lunedì 29 settembre 2014 19:37
A: sr-users at lists.sip-router.org
Oggetto: Re: [SR-Users] R: Re: R: Re: RTPPROXY & BRANCH

On 09/29/14 13:29, Frank Carmickle wrote:
> 
> On Sep 29, 2014, at 1:24 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:
> 
>> On 09/29/14 13:19, Frank Carmickle wrote:
>>>
>>> On Sep 29, 2014, at 1:14 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:
>>>>
>>>> This may work with rtpengine, as it will open new ports for answers 
>>>> come from different endpoints. But the final two-way association 
>>>> for the actual call may still end up broken, as it has no way of 
>>>> knowing which client ends up receiving the call (unless they do a final
re-invite).
>>>
>>> But it should see the 200.  Shouldn't that be enough?
>>
>> Unfortunately it doesn't see SIP codes, it only sees SDP bodies and 
>> some particular details from the SIP message. 200 OK would be 
>> translated to an "answer", but not every answer is from a 200 OK, so 
>> you can't use that to break other associations. Perhaps this would be 
>> a nice addition to have in the future.
> 
> I will argue that the only thing that is an answer is a 200.  A progress,
early media or pre_answer is a 183.  Yes both 183s and 200s need to set up
media but as you know there could be many 183s and only one 200.
> 
> If the UA sends an sdp with both the 183 and the 200 would this work
correctly?

That might just work, as the last answer rtpengine sees determines the
association with the offer.

cheers

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


---
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus.
http://www.avast.com