SIP RA 1.2 bug?

[IsmaeL]

Hi,

I am using the JSIP RA 1.2 (from 1.2.4 GA) and it seems the
DialogActivity interface implementation (DialogWrapper class) has a
problem. The method createRequest(incomingRequest) inverts the From
and To headers of the incomingRequest in the outgoingRequest.

Has anyone tested that method? Thanks for your time.

[Bartosz Baranowski]

SipRa 1.2 ? Are You sure its this?

--
Bartosz Baranowski
JBoss R & D
==================================
Word of criticism meant to improve is always step forward.

[Ismael]

It is the sip11 resource adaptor. Isn't that the JSIP 1.2 RA
implementation? Here is my scenario (very simple though):
outgoingRequest = dialogActivity.createRequest(incomingRequest). when
I log, I can clearly see that the from and to headers are inverted
from one request to the other. The B2BUA example uses the same
scenario (in the forwardRequest method), so I was wondering if you
have tested that SBB.

On Mar 3, 9:49 am, Bartosz Baranowski <baran...@gmail.com> wrote:
> SipRa 1.2 ? Are You sure its this?
>

[Bartosz Baranowski]

Hi Could You please provde me with messages YOu are exchanging?
ive been trying to figure case when this might happen. Only place could be: fillRequestHeaders and this could happen only in case fork happens.

[Ismael]

Hi Bartosz,

I just uploaded the wireshark capture file. Some infos:

I am using MobiCents as a SIP AS with Open IMS Core. All components
are listening on local loopback like this: PCSCF(4060), ICSCF(5060),
SCSCF(6060) and SIP RA (7070). MobiCents is used as SIP application
server on both originating and terminating sides. IMS Clients (IMS
Communicator) are listening on 192.168.0.107. I have a B2BUA SBB
deployed on MobiCents and using almost the same algo than the example
given in jslee 1.1 spec (more importantly the
dialogActivity.createRequest(incomingRequest) is used to create the
outgoing request for the terminating side). As you can see in the
capture file, MobiCents inverts the from and to headers twice
(originating and terminating)! No fork is done in the scenario.

Hope that's enough info :-)

Thanks for your time.

[Bartosz Baranowski]

Hi
I dont see any atachments.

[Ismael]

I was not able to attach the capture file to my reply.
Instead I uploaded the file: trace_SIP_RA.cap .

On Mar 5, 1:43 pm, Bartosz Baranowski <baran...@gmail.com> wrote:
> Hi

[Bartosz Baranowski]

Where did You upload it ?

[Ismael]

:-) in the Files section. File name: trace_SIP_RA.cap .

[Ismael]

I found out another thing: the SIP RA does not respect the spec
concerning the Route header. In the spec (section section D.9,
DialogActivity interface) it is stated that if the application doesn't
specify the request's route path, the RA should compute it. But the
problem is that I set up my own route header (the request should go
back to the SCSCF through the ISC interface) but as you can see in the
capture file, the SIP RA just drops it!

Cheers,

[Bartosz Baranowski]

Hmm. Route header is on ignore list in case of forking. otherwise its JSIP route that is filled. Im checking out fresh repo snapshost, once its done I will take a peek.

[Ismael]

To try my scenario just do this:
receive an INVITE;
create a Dialog from its server transaction;
create an outgoing dialog from that incoming dialog (createDialog
(inDialog, false).
create an outgoing INVITE from the incoming INVITE by using
outDialog.createRequest(inRequest).
set your own route headers
send the request with outDialog.sendRequest(outRequest).


Cheers,

[Bartosz Baranowski]

Ok, seems valid issue. Checked it with b2b example. happens also there.
Issue:
http://code.google.com/p/mobicents/issues/detail?id=598

[Ismael]

Have you tested the route header issue? the patch seems to correct
only the from/to headers problem.
did you receive my email?

[Bartosz Baranowski]

Nope, Im taking care of something else at the moment. Can You describe it:

ie: RA overwrites route headers You put into message after its created?
by the way - in wireshark dump I see something weird:

H1 ---> H2

message has RouteHeader set to H1.

[Ismael]

Yes the RA overwrites the route headers i set up after the dialog
activity creates the request.

> by the way - in wireshark dump I see something weird:
>
> H1 ---> H2
>
> message has RouteHeader set to H1.

Not sure about what you're saying.

[Bartosz Baranowski]

Node sends message to another with 3 route headers - with 2 pointing to src node.

Looked through whole code. in jsip route headers are only filled  one message creation. Same in RA. If You could send me sipp scenario and example service that replicates that would help, Otherwise Im looking for a problem in a haystack.  Please check that route headers are set correctly. As I mentioned message have something like:
Record-Route: <sip:m...@scscf.sylitech.com:6060;lr>
Route: <sip:or...@mobicents.sylitech.com:7070;lr>, <sip:isc...@scscf.sylitech.com:6060;lr;s=1;h=1;d=0;a=7369703a626f624073796c69746563682e636f6d>
Record-Route: <sip:m...@pcscf.sylitech.com:4060;lr>
....
....
Route: <sip:or...@scscf.sylitech.com:6060;lr>

and this is message originatin from 6060, mostly confusing.


About IMS we are gathering knowledge, diggingt through 24.xxx, 23.xxx docs. If You want to help another brain is most welcome.

[Ismael]

Hi,

Still working on this problem. I have found out this: the Route header
is omitted in the dialogActivity.createRequest(in) implementation, so
is the Record-Route header. Moreover, upon receival of the INVITE
(javax.sip.request.INVITE), the sleeProvider.createDialog
(serverTransaction) returns a null Dialog (I know the dialog is in
null state at this point, but even the dialogId [comprised of from, to
and call id headers] is null) is that normal?. I am working on the
sipp sceanario and it should be ready soon.

Regards,


Ismael.

[Bartosz Baranowski]

Hi Ismael
Please see inline response

On Mon, Mar 16, 2009 at 9:15 AM, Ismael <mori...@gmail.com> wrote:

Hi,

Still working on this problem. I have found out this: the Route header
is omitted in the dialogActivity.createRequest(in) implementation, so
is the Record-Route header.

If its not a forking situation we expect JSIP to handle it. if it does not we should report bug  (maybe)  or hack it in wrappers.

Moreover, upon receival of the INVITE
(javax.sip.request.INVITE), the sleeProvider.createDialog
(serverTransaction) returns a null Dialog (I know the dialog is in
null state at this point, but even the dialogId [comprised of from, to
and call id headers] is null) is that normal?. I am working on the
sipp sceanario and it should be ready soon.

If its a dump info this could mean that it cant be fully computed at the moment, iirc wrappers hide this until id is fully known. Does it throw any expcetion?

 

Regards,


Ismael.

[Ismael]

Hi,

> If its not a forking situation we expect JSIP to handle it. if it does not
> we should report bug  (maybe)  or hack it in wrappers.

No it is not a forking situation.

> If its a dump info this could mean that it cant be fully computed at the
> moment, iirc wrappers hide this until id is fully known. Does it throw any
> expcetion?

No , I do not see any exception thrown in JBoss/MobiCents log.

IsmaeL

[Bartosz Baranowski]

HI Ismael could I see log dump from console?

[IsmaeL Camara]

Hi,
Sorry for the delay. Here is my scenario. I attached the Maven project where you can see the code of the SBB.
You will need the open ims core. You can look out my blog to see how to integrate Mobicents. Then after registering two IMS clients, make a call from one to another as described in my blog post. That's too much work I know but it is the best I could do for the time being.

If you have any questions, let me know.


Hope it helps.

Cheers,

--
El Hadj Mory IsmaeL Camara
Telecommunications & Software Engineer
mobile: (+33) 06 24 89 19 02
http://cmorismael.blogspot.com

[Bartosz Baranowski]

Great, that shoudl help a lot. Will let You know outcome.

[Vatemu]

Hi all,

I noticed the same problem, but Ismael, you .zip is the result of
trace.cap? In that case, the buf is not solve, rigth?

On 19 mar, 11:23, Bartosz Baranowski <baran...@gmail.com> wrote:
> Great, that shoudl help a lot. Will let You know outcome.
>
>
>
> On Thu, Mar 19, 2009 at 1:32 AM, IsmaeL Camara <morism...@gmail.com> wrote:
> > Hi,
> > Sorry for the delay. Here is my scenario. I attached the Maven project
> > where you can see the code of the SBB.
> > You will need the open ims core. You can look out my blog to see how to
> > integrate Mobicents. Then after registering two IMS clients, make a call
> > from one to another as described in my blog post. That's too much work I

> > know but it is the best I could do for the time being.[?]

>
> > If you have any questions, let me know.
>
> > Hope it helps.
>
> > Cheers,
>
> > --
> > El Hadj Mory IsmaeL Camara
> > Telecommunications & Software Engineer
> > mobile: (+33) 06 24 89 19 02
> >http://cmorismael.blogspot.com
>
> --
> Bartosz Baranowski
> JBoss R & D
> ==================================
> Word of criticism meant to improve is always step forward.
>

>  328.png
> < 1 KBVerDescargar

[Bartosz Baranowski]

Neither me nor Alex were able to reproduce. So up till now its not confirmed from our side. Maybe we missconfigure openims or load generated from VMWare is to high, Ive sent src of RA that should provide some debug but he was not able to run due mvn dependencies issues. Once he provides me with log I will fix that and post zip here so one of You can run it.

[Vanessa Tejada Muñoz]

Hi,

first of all, I reproduced the error. The invite is forwarded by the AS-b2bua, but the next problem is in ACK.

The 200 OK lost the recordroute headers in the AS (when you create a new response for the incommingDialog ) then, when 200 OK arrive at uac the route header is not correct and don't reach the AS (you only have the record route o pcscf and scscf).
I added the AS in the recordroute, and the AS is reached but ACK is not forwarded inside, why? i don't know... neither exception nor transaction error... nothing :S

I don't know if this information can be useful for you.

Regards

--
Vanessa Tejada

[Vanessa Tejada Muñoz]

Hi,


to be more specific, the ACK is created in the server in forwardRequest like this:

if (incomingRequest.getMethod().equals(Request.ACK)) {
            // Just forward the ACK statelessly - don't need to remember
            // transaction state
            Request outgoingRequest = out.createRequest(incomingRequest);
            out.sendAck(outgoingRequest);

The thing is, nothing happens! In the logs, the transaction are terminated and the ACK is not forwarded.

Any idea?


Regards

--
Vanessa Tejada

[Bartosz Baranowski]

Great,. finally some clues. Will look into once Im done with release process. Thanks a lot.

[Vanessa Tejada Muñoz]

Ok I have one more :)

We cannot create an ACK request through the incommingRequest, becasuse the transaction is terminated for the incomingDialog. If you create the ACk like:

Request ack = out.createAck(long seq_number);
out.sendACK(ack);

It works OK, becasuse you create the ACK corresponding to the outDialog (which has an initial INVITE also), but the problem is.... what happen if I have private headers in the ACK's incommingDialog? I mean. Imagine I have an specific field in SDP on INVITE message, these contents are copied when you make outdialog.createRequest(incomingRequest)?

Thanks

--
Vanessa Tejada

[Bartosz Baranowski]

Not sure if I got it correctly. But:
- when requested is created content is copied from original.
- when there is estabilished dialog we put all responsibility on it to maintain dialog headers.

If this does not clear things, please post some scenario, this always clarifies.

[Vanessa Tejada Muñoz]

I checked it, and only ocurrs int private headers, I mean, private headers are not forwarded in different dialogs.

I create the outACk with outDialog, and copy all headers except the headers which cannot change (call-id, from, to, content, etc), then, the private headers are forwarded.

:) finally, the only drawbacks I found are:

1 - In responses, it could be neccesary add a recordroute header about the AS. ACK don't reach the AS even though  in 200 OK the AS is not added, only the scscf and pcscf.

2 - You cannot create the ack like:

Request outgoingRequest = out.createRequest(incomingRequest);

out.sendAck(outgoingRequest);

because the incomming transaction are terminated... you have to use the outDialog to create the corresponding ACK such as:

Request ack = out.createAck(long seq_number);
out.sendACK(ack);

3 - In the ACk, you create a new Request about outDialog, then, the private headers are not copied, because you don't create the outgoingReq using the incomingReq.


The scenario I use is the same of the example, one private header was added to check if they are copied also in ACK situation.

These are my comment about sip11-b2b-example over IMS (Fokus) until now. When you change this, the communication is perfect!

I hope have been helpful :)



--
Vanessa Tejada

[Jean Deruelle]

On Fri, Apr 24, 2009 at 11:14 AM, Vanessa Tejada Muñoz <vat...@gmail.com> wrote:

I checked it, and only ocurrs int private headers, I mean, private headers are not forwarded in different dialogs.

I create the outACk with outDialog, and copy all headers except the headers which cannot change (call-id, from, to, content, etc), then, the private headers are forwarded.

:) finally, the only drawbacks I found are:

1 - In responses, it could be neccesary add a recordroute header about the AS. ACK don't reach the AS even though  in 200 OK the AS is not added, only the scscf and pcscf.

if you want the AS to get subsequent requests (ie if it acted as a proxy) then yes you need it to record route as per RFC3261
if the AS is acting like a B2BUA I don't see why you need to record route.
some wireshark traces would be interested here

2 - You cannot create the ack like:

Request outgoingRequest = out.createRequest(incomingRequest);

out.sendAck(outgoingRequest);

because the incomming transaction are terminated... you have to use the outDialog to create the corresponding ACK such as:

JAIN SIP specification is forbidding the usage of dialog.createRequest method for an ACK and PRACK. If the example is using this then this is bad indeed and you may want to file an issue about it.

[Vanessa Tejada Muñoz]

In case of B2BUA it is neccesary the AS in RecordRoute header.

If you simulate a basic scenario such as:

UAC---------AS---------UAS

When the UAC receive the 200 OK, it is used the 200OK's routes in UAC ACK. In this case, you only have scscf and pcscf, then the ACK doesn't reach de AS!

I'm not able to send the wireshark traces right now... tomorrow I'll send them.


Regards,

--
Vanessa Tejada
Nethalis Solutions S. L.

[Bartosz Baranowski]

OK tried to make sense out of it, maybe trace will shed some light here. See inline.

On Mon, Apr 27, 2009 at 6:31 PM, Vanessa Tejada Muñoz <vat...@gmail.com> wrote:

In case of B2BUA it is neccesary the AS in RecordRoute header.

If you simulate a basic scenario such as:

UAC---------AS---------UAS

When the UAC receive the 200 OK, it is used the 200OK's routes in UAC ACK. In this case, you only have scscf and pcscf, then the ACK doesn't reach de AS!

Well if there is no route/record route pointing to AS no wonder it does not receive ACK, is there something else expected in this case - SIP rfc does not mention that, does it?
Record Route/route headers should be filled with by dialog.
When ACK/PRACK is created no original request is present, so if there are headers that are not maintained  by SIP, its application responsigiblity.

I'm not able to send the wireshark traces right now... tomorrow I'll send them.

Woudl be helpful to udnerstand.

[Jean Deruelle]

It should not. B2BUA acts as a final endpoint (you've got to see it as a UAC/UAS too) so nothing specific should be required.

your scenario when you think of the B2BUA would be like this:
UAC---------  UAS (B2BUA incoming leg)  UAC(B2BUA outgoing leg) ---------UAS

Not sure where the xcscf are in your scenario though

[Vanessa Tejada Muñoz]

Hi,

I attached the traces fo wireshark.

My B2BUA AS is in 5060 port. The UAC is in 5071 and the UAS is in 5073. Filter the trace with SIP.

I hope be helpful to understand me.


Regards.

[Jean Deruelle]

Actually this confuses me even more :-)

The call flow seems like this :

UAC (192.168.34.52:5071)           PCSCF (192.168.34.37:4060)           SCSCF (192.168.34.37:6060)           B2BUA -first leg  (192.168.34.52:5060)            B2BUA -second leg  (192.168.34.37:5060)           UAS (192.168.34.52:5073)

           ---------------------    INVITE ---------------->
                                                                         ---------------------------    INVITE ---------------->
                                                                                                                                  -------------------------    INVITE ---------------->
                                                                                                                                                                                                       ---------------------    INVITE ---------------->
                                                                                                                                  <-----------------------------------------------------------    INVITE --------------------------------------------------
                                                                         <---------------------    INVITE ---------------------
                                                                         ----------------------------------------------------------------------------------------------------------------------------------    INVITE ------------------------------------------------------------------------------------>

So the thing I don't understand :
It seems your B2BUA is spread on 2 machines 192.168.34.52 and 192.168.34.37 ? Or does it uses multiple interfaces, in such case why does an INVITE is sent from interface 192.168.34.52 to 192.168.34.37 ?

What is wrong :
Also the INVITE that goes out of what seems to be the B2BUA second leg 192.168.34.37:5060 back to the SCSCF doesn't have a new call id, the Via Headers from the pevious request are not removed and the contact header is incorrect (it should be the IP address and port of the B2BUA leg)

Hope this helps
Jean

[Vanessa Tejada Muñoz]

OK,

192.168.34.52_5060 is where mobicents are running, the same IP and different ports is for UAC and UAS.
192.168.34.37 is the openIMS (Fokus).

I'm using the example:

http://groups.google.com/group/mobicents-public/web/jain-slee-example-sip-b2b?pli=1


I don't know why the call-id is the same, but, when the dialog is confirmed, I can see in the logs diferent ID for Dialogs. In the url, you can see that I asked the same thing about call-id... and read the responses...

The example works for me if I change what I said in other email:

- Add the AS as route in 200 OK.
- The ACK in the AS have the create ths reques using outgoingDialog.

--
Vanessa Tejada

[Bartosz Baranowski]

Let me get this straight

On Tue, Apr 28, 2009 at 10:54 AM, Vanessa Tejada Muñoz <vat...@gmail.com> wrote:

OK,

192.168.34.52_5060 is where mobicents are running, the same IP and different ports is for UAC and UAS.
192.168.34.37 is the openIMS (Fokus).

I'm using the example:

http://groups.google.com/group/mobicents-public/web/jain-slee-example-sip-b2b?pli=1


I don't know why the call-id is the same, but, when the dialog is confirmed, I can see in the logs diferent ID for Dialogs. In the url, you can see that I asked the same thing about call-id... and read the responses...

The example works for me if I change what I said in other email:

- Add the AS as route in 200 OK.

- receive 200 on outgoingDialog, than You need to add route (or I would say record route) header? on response created via incomingDialog.createResponse
In create response we omit headers:
        headersToOmmit.add(RouteHeader.NAME);
        headersToOmmit.add(RecordRouteHeader.NAME);
        headersToOmmit.add(ViaHeader.NAME);
        headersToOmmit.add(CallIdHeader.NAME);
        headersToOmmit.add(CSeqHeader.NAME);
        headersToOmmit.add(ContactHeader.NAME);

Possibly RecordRoute should be allowed but Im not sure of implications. Can You try commenting it out?

- The ACK in the AS have the create ths reques using outgoingDialog.

Not following this one still.

[Jean Deruelle]

See inline

On Tue, Apr 28, 2009 at 10:54 AM, Vanessa Tejada Muñoz <vat...@gmail.com> wrote:

OK,

192.168.34.52_5060 is where mobicents are running, the same IP and different ports is for UAC and UAS.
192.168.34.37 is the openIMS (Fokus).

I'm using the example:

http://groups.google.com/group/mobicents-public/web/jain-slee-example-sip-b2b?pli=1


I don't know why the call-id is the same, but, when the dialog is confirmed, I can see in the logs diferent ID for Dialogs. In the url, you can see that I asked the same thing about call-id... and read the responses...

I commented on it too now. This is incorrect, a new Call Id should be used.
 

The example works for me if I change what I said in other email:

- Add the AS as route in 200 OK.

This is wrong too IMHO, did you try setting the Contact to the IP address and port of the AS ?
RFC 3261 Section 12.1.1 UAS behavior states  that  :
"When a UAS responds to a request with a response that establishes a
   dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
   header field values from the request into the response (including the
   URIs, URI parameters, and any Record-Route header field parameters,
   whether they are known or unknown to the UAS) and MUST maintain the
   order of those values.  The UAS MUST add a Contact header field to
   the response.  The Contact header field contains an address where the
   UAS would like to be contacted for subsequent requests in the dialog
   (which includes the ACK for a 2xx response in the case of an INVITE)."

- The ACK in the AS have the create ths reques using outgoingDialog.

OK

[Jean Deruelle]

Wrt to the Call Id problem:
Bartek pointed out to me in the link provided by vanessa below that JSLEE 1.1 spec allows it :
Annex D - page 501 :
"The getNewDialog(DialogActivity, boolean) method:
This method creates a new SIP Dialog, starts a new Activity in the SLEE, and returns the new DialogActivity.
The new Dialog is a UAC Dialog. This method copies the local and remote addresses
from incoming Dialog to the newly created Dialog. It generates a new local tag and the remote tag will be
null. If the useSameCallId parameter is true then the newly created Dialog will use the Call ID from
the incoming Dialog, otherwise a new Call ID is generated.
This method takes the following arguments:
incomingActivity – This specifies the incoming Dialog which is used to copy headers from.
useSameCallId – This specifies whether or not the newly created Dialog uses the same call ID as the
incoming Dialog."

IMHO This contradicts with RFC3261 Section 8.1.1.4 Call-ID :

"The Call-ID header field acts as a unique identifier to group
   together a series of messages.  It MUST be the same for all requests
   and responses sent by either UA in a dialog.  It SHOULD be the same
   in each registration from a UA.
   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA."

In the case of JSLEE, a new dialog is created, the from tag will be new, the to tag will be null so a new Call Id should be used no matter what as stated by the RFC.
Also for further confirmation, Sip Servlets 1.0 used to have the same method and it has been deprecated in 1.1. See JSR 289 Section 12.2 Creating new B2BUA Request (page 129) :
"The SipFactory.createRequest(SipServletRequest origRequest, boolean sameCallId) method has been deprecated in this specification as the usage of this method with sameCallId flag as "true" actually breaks the provisions of [RFC 3261] where the Call-ID value is to be unique accross dialogs. Instead, the use of B2buaHelper.createRequest(SipServletRequest origRequest) is recommended."

[Bartosz Baranowski]

And regarding headers - route headers and similar should nto be copied from response received on outgoign dialog - as it would also break rfc, wouldnt it?

[Vladimir Ralev]

I am not sure it contradicts because b2bUA is not UAC and it is not UAS and the spec mostly refers strictly to UACs (i.e. phones) to not use the same call-id. The other UAs just need to have the means. Looks to me that a good lawyer could pass that in the court :)

[Jean Deruelle]

All unknown headers and Route, From and To headers are copied from original request to the new one. (from tag will be new and to tag will be null)
Record-Route and Via header fields are not copied.
Regarding responses generation, they then follow the rules of RFC3261

[Jean Deruelle]

It does. See http://en.wikipedia.org/wiki/Back-to-back_user_agent

[Eduardo Martins]

I really think the B2BUA is an exception on this matter, to keep the
call id is not an issue because it b2bua is a dialog only behavior,
and the dialog ids will not be the same. I'm not sure but sometimes it
may make sense, since applications may use message data related with
authentication/authorization, which may depend on original call id. I
think I saw something like that being discussed in IETF sip mail lists
some time ago.

Anyway, it is a boolean flag, if you want to use a diff call-id you can.

-- Eduardo

[Vanessa Tejada Muñoz]

Yes, that is.

In the example, the outgoingDialog is created with boolean falg = true, then it is used the same call-id. I'll check what happend with flag at false.

Look at this:

https://developer.opencloud.com/devportal/devportal/apis/ocsip/2.0/ocsip-2.0-javadoc/jsip-ratype/net/java/slee/resource/sip/SleeSipProvider.html#getNewDialog(net.java.slee.resource.sip.DialogActivity,%20boolean)

[Vanessa Tejada Muñoz]

About RecordRoute header,

I understand that the problem is when we create the response like:

Response outgoingResponse = out.createResponse(st, receivedResponse);

And the Contact-Header must be the AS and not the UAS, rigth?

I'll try it and check if in that case it is not neccesary add the AS as RecordRoute.

[Jean Deruelle]

Not sure because in Sip Servlets this was specifically removed for the B2BUA case and one of the expert group member was from the IETF (Chris Boulton).
Anyway not sure if this is a big deal but IMHO to be a good SIP citizen this flag should stay to false forever :-)

On Tue, Apr 28, 2009 at 12:57 PM, Eduardo Martins <emma...@gmail.com> wrote:

[Jean Deruelle]

Yes

[Bartosz Baranowski]

On Tue, Apr 28, 2009 at 1:19 PM, Vanessa Tejada Muñoz <vat...@gmail.com> wrote:

About RecordRoute header,

I understand that the problem is when we create the response like:

Response outgoingResponse = out.createResponse(st, receivedResponse);

And the Contact-Header must be the AS and not the UAS, rigth?

When message is forged contact is set to localPart of current dialog (one taht forges message.)

I'll try it and check if in that case it is not neccesary add the AS as RecordRoute.

This is the point, Im not sure if we are required to put this as "B2B Helper" its not mentioned. JD?

--

Vanessa Tejada
Nethalis Solutions S. L.

[Vanessa Tejada Muñoz]

OK, I have a feedback :)

According to SIP Spec, the call-id have to be different for the outgoingDialog. If you change the falg when create the dialog, the call-id is new, and the communication is perfect

DialogActivity outgoingDialog = sipFactoryProvider.getNewDialog(incomingDialog, false);

Finally, the example includes a method called "getContactHeader" which returns the ContactHeader with AS parameters.
Then, If you add this in the forwardResponse:

Response outgoingResponse = out.createResponse(st, receivedResponse);

try{

if (outgoingResponse.getHeader(ContactHeader.NAME) != null)
                outgoingResponse.removeHeader(ContactHeader.NAME);
outgoingResponse.addHeader(getContactHeader());

}catch(...){...};

Now, It works perferct (without record route with AS information) over openIMS.


Best Regads,

[Jean Deruelle]

Great :-)
I'm glad the recommendations were helpful.
Those modifications were done in the SIP RA or the b2bua example ?

[Bartosz Baranowski]

One thing, please see inline.

On Tue, Apr 28, 2009 at 8:00 PM, Vanessa Tejada Muñoz <vat...@gmail.com> wrote:

OK, I have a feedback :)

According to SIP Spec, the call-id have to be different for the outgoingDialog. If you change the falg when create the dialog, the call-id is new, and the communication is perfect

DialogActivity outgoingDialog = sipFactoryProvider.getNewDialog(incomingDialog, false);

Finally, the example includes a method called "getContactHeader" which returns the ContactHeader with AS parameters.
Then, If you add this in the forwardResponse:

Response outgoingResponse = out.createResponse(st, receivedResponse);

try{

if (outgoingResponse.getHeader(ContactHeader.NAME) != null)
                outgoingResponse.removeHeader(ContactHeader.NAME);
outgoingResponse.addHeader(getContactHeader());

SIP 1.1 RA puts incomingDialog.getLocalParty() as contact, so in other words its a bug, since one should not have to put contact header, will make quick fix and send patch for verification.

}catch(...){...};

Now, It works perferct (without record route with AS information) over openIMS.


Best Regads,

--
Vanessa Tejada
Nethalis Solutions S. L.

[Bartosz Baranowski]

Hi Vanessa
Made small hack to accomodate changes. Could You please run this against YOur setup to verify taht it works on Your end also?

[Vanessa Tejada Muñoz]

OK, I'll run it, but I'm not available and I'll do it on Monday :)

[Jean Deruelle]

Happy Labor day everyone :-)

[Vanessa Tejada Muñoz]

only one detail... I should toapply the patch over the RA or b2b example?

--

[Bartosz Baranowski]

http://code.google.com/p/mobicents/issues/detail?id=680&colspec=ID%20Priority%20Component%20Milestone%20Version%20Release%20Type%20Status%20Owner%20Summary&start=100 this goes for sip ra, Im able to make a call between two nodes with only b2b example in the middle.

[Bartosz Baranowski]

Just double checked traffic and I see ACK is not delivered to other side - iIt seems correctly created on client - but its not forwarded to AS. Trying to make sense out of it.

[Bartosz Baranowski]

Further investigation shows that jSIP could make wrong route header creation - it does not reverse RecordRoute, but thats just a guess for now. I get on AS:

REQUEST: ACK sip:89.77.161.136:5060 SIP/2.0

Via: SIP/2.0/UDP 89.77.205.87:6060;branch=0,SIP/2.0/UDP 89.77.205.87:4060;branch=0,SIP/2.0/UDP 89.77.161.136:2231;rport=2231;branch=z9hG4bK18716
Max-Forwards: 15
From: <sip:al...@open-ims.test>;tag=9760
To: <sip:b...@open-ims.test>;tag=1002

CSeq: 401 ACK
Call-ID: M-199d5fd2833814fa3a8d47e4bd3b536d
P-Access-Network-Info: ADSL; utran-cell-id-3gpp=00000000

Privacy: none
P-Asserted-Identity: <sip:al...@open-ims.test>
Content-Length: 0

which is sent out as:

ACK sip:89.77.205.87:5061 SIP/2.0

Call-ID: 0d73344c65ae1a15...@89.77.161.136
CSeq: 401 ACK

From: <sip:al...@open-ims.test>;tag=c59c43db
To: <sip:b...@open-ims.test>;tag=1002
Route: <sip:m...@scscf.open-ims.test:6060;lr>,<sip:m...@scscf.open-ims.test:6060;lr>,<sip:m...@pcscf.open-ims.test:4060;lr>

Via: SIP/2.0/UDP 89.77.161.136:5060,SIP/2.0/UDP 89.77.205.87:6060;branch=0,SIP/2.0/UDP 89.77.205.87:4060;branch=0,SIP/2.0/UDP 89.77.161.136:2231;rport=2231;branch=z9hG4bK18716
Max-Forwards: 15

P-Access-Network-Info: ADSL; utran-cell-id-3gpp=00000000
Privacy: none
P-Asserted-Identity: <sip:al...@open-ims.test>
Content-Length: 0

but i never getrs to other client.

[Vanessa Tejada Muñoz]

I checkout "http://mobicents.googlecode.com/svn/trunk/servers/jain-slee/resources/sip11/" to apply the patch but I have a problem in the code:

---
private void initializeNamingContext() throws NamingException, NullPointerException, UnrecognizedResourceAdaptorEntityException {
        SleeContainer container = SleeContainer.lookupFromJndi();
       
        serviceContainer = container;
        // activityContextFactory =
        // serviceContainer.getActivityContextFactory();
        tm = serviceContainer.getTransactionManager();
        ResourceAdaptorEntity resourceAdaptorEntity = ((ResourceAdaptorEntity) container
                .getResourceManagement().getResourceAdaptorEntity(this.bootstrapContext
                        .getEntityName()));
   
        ResourceAdaptorTypeID raTypeId = resourceAdaptorEntity.getInstalledResourceAdaptor().getRaType().getResourceAdaptorTypeID();

        this.acif = new SipActivityContextInterfaceFactoryImpl(
                resourceAdaptorEntity.getServiceContainer(),
                this.bootstrapContext.getEntityName(), this,
                resourceAdaptorEntity.getServiceContainer()
                        .getTransactionManager());

       
        resourceAdaptorEntity.getServiceContainer()
                .getResourceManagement().getActivityContextInterfaceFactories()
                .put(raTypeId, (ResourceAdaptorActivityContextInterfaceFactory)this.acif);

----


The error said:

"The method XXXXX is undefined for the type ResourceAdaptorEntity"

--
Vanessa Tejada

[Bartosz Baranowski]

errr, its jslee 1.1 . Trunk is used for dev for 1.1 specs slee container. Use http://code.google.com/p/mobicents/source/browse/#svn/branches/servers/jain-slee/1.x.y
I succeded on making call with full exchange, based on pute b2b example.

[Vanessa Tejada Muñoz]

I'm sorry again...

what about this error in maven?

Cannot find artifact for parent POM: org.mobicents:mobicents-jainslee-server::1.2.5.GA-SNAPSHOT for project org.mobicents.resources:sip11-parent:pom:[inherited] at D:\Nethalis\\workspace\sip11-parent\pom.xml

--
Vanessa Tejada

[Bartosz Baranowski]

trunk is for development only. working copy is under link Ive posted.

[Vanessa Tejada Muñoz]

I chaned the project, yesterday in the afternoon I checked out this:

http://mobicents.googlecode.com/svn/branches/servers/jain-slee/1.x.y/resources/sip11/

I applied the patch correctly, but, Eclipse don't allow me execute maven build because of this error :S

--
Vanessa Tejada

[Bartosz Baranowski]

Which error?

[Vanessa Tejada Muñoz]

This:

Cannot find artifact for parent POM: org.mobicents:mobicents-

jainslee-server::1.2.5.GA-SNAPSHOT for project org.mobicents.resources:sip11-parent:pom:[inherited] at D:\Nethalis\\workspace\sip11-parent\pom.xml

--
Vanessa Tejada

[Bartosz Baranowski]

You must have checked snapshot of a release. change versions to what YOu have in older pom.

[Vanessa Tejada Muñoz]

I have applied the patch and solved my Maven problems :)
I removed the code I added about contact-header.

Finally, I run the b2bua example without success. The logs said:

17:17:48,984 ERROR [STDERR] javax.sip.SipException: Contact Header is mandatory for the OK to the IN
VITE
17:17:48,984 ERROR [STDERR]     at gov.nist.javax.sip.stack.SIPServerTransaction.sendResponse(SIPSer
verTransaction.java:1338)