Hi list,

I'm using openser1.1.1 and just found a problem. I wish to not upgrade right now as I'm using serweb...

I got an issue: a UA is sending a PUBLISH, the server is relaying the PUBLISH to 2 sip addresses which both answer 501. openser is not sending 501 but instead is choosing to answer 407 as the best response...

I think 501 is expected... Any idea where could be the problem so I can look at the code and try to fix this!

tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/

On Wed, 16 Jan 2008, Iñaki Baz Castillo wrote:

On Wednesday 16 January 2008 14:04:41 Aymeric Moizard wrote:

...

Hi list,

I'm using openser1.1.1 and just found a problem. I wish to not upgrade right now as I'm using serweb...

I got an issue: a UA is sending a PUBLISH, the server is relaying the PUBLISH to 2 sip addresses which both answer 501. openser is not sending 501 but instead is choosing to answer 407 as the best response...

¿Sure it is "407 Proxy Authentication Required"? isn't it "406 Not Acceptable" or "405 Method Not Allowed"?

Yes it is. I would not mind about 406 or 405, but 407 introduce a loop here.

...

I think 501 is expected... Any idea where could be the problem so I can look at the code and try to fix this!

I think the behaviour is correct:

5XX reply means "server reply" and OpenSer is not falling at all so it shouldn't reply with a 5XX.

I don't feel you are right:

What about the case where 2 "servers" are sending back 501? In this case, openser will modify it to become 407. That's a problem.

Just for information: from my knowledge, 5xx answers are UAS answers, not dedicated to "proxy" -> they are dedicated to servers side which might be endpoints (gateway...) from my point of view.

For example, there is no reason that an endpoint should not be able to answer with "505 Version Not Supported" or "513 Message Too Large".

Any hint on where the code should be modified to get a different behavior for this specific case?

tks, Aymeric

-- Iñaki Baz Castillo ibc@in.ilimit.es

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

This sounds very strange. Are you sure that the 407 is produced internally? Have you inspected the log files?

regards klaus

Aymeric Moizard schrieb:

Hi list,

I'm using openser1.1.1 and just found a problem. I wish to not upgrade right now as I'm using serweb...

I got an issue: a UA is sending a PUBLISH, the server is relaying the PUBLISH to 2 sip addresses which both answer 501. openser is not sending 501 but instead is choosing to answer 407 as the best response...

I think 501 is expected... Any idea where could be the problem so I can look at the code and try to fix this!

tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/

---

Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users

Hi Iñaki,

all the transformation should work with avps and script variables also..See the examples: http://www.openser.org/dokuwiki/doku.php/transformations:1.3.x#examples

why do you say it doesn't? do you get some errors ?

Regards, Bogdan

Iñaki Baz Castillo wrote:

On Wednesday 16 January 2008 13:42:34 Klaus Darilion wrote:

...

{uri.host}

(same as {uri.domain})

Return the domain part

http://www.openser.org/dokuwiki/doku.php/transformations:1.3.x

Thanks Klaus, it works using: $(rt{uri.host}) ;)

I already know about those {uri} tansformation but unfortunatelly the are not allowed for variables or AVP's:

$(var(name){uri.host}) $(avp(s:name){uri.host})

Those are not allowed and they will fail in execution time even if they contain a valid SIP URI.

Thanks a lot!

On Wednesday 16 January 2008 16:34:40 Iñaki Baz Castillo wrote:

It doesn't fails if SIP URI doesn't contain "<" and ">".

So I assume that, in my case, it will fail if a UAC generates a "Refer-To" with "<" and ">", while it's perfectly valid according to RFC 3515:

Refer-To: sip:carol@cleveland.example.org;method=SUBSCRIBE

Oh, but it doesn't fail because $rt takes off the "<" and ">" symbols from the URI. :)

So forget me, it's not a bug. The SIP URI in the AVP or variable should be without < > (as a good SIP URI it's) ;)

El Jueves, 17 de Enero de 2008, Klaus Darilion escribió:

Iñaki Baz Castillo schrieb:

...

On Wednesday 16 January 2008 16:34:40 Iñaki Baz Castillo wrote:

...

It doesn't fails if SIP URI doesn't contain "<" and ">".

So I assume that, in my case, it will fail if a UAC generates a "Refer-To" with "<" and ">", while it's perfectly valid according to RFC 3515:

Refer-To: sip:carol@cleveland.example.org;method=SUBSCRIBE

Oh, but it doesn't fail because $rt takes off the "<" and ">" symbols from the URI. :)

So forget me, it's not a bug. The SIP URI in the AVP or variable should be without < > (as a good SIP URI it's) ;)

But this would be other very useful transformation - getting display name and SIP URI from name-addr (should work with plain SIP URI too).

name-addr = [ display-name ] LAQUOT addr-spec RAQUOT

Now I want to allow callerid hidden calls if the UAC sends an INVITE with:

From: "Anoymous" sip:anonymous@anonymous.invalid P-Preferred-Identity: "Iñaki" sip:ibc@domain.org Privacy: id

To authenticate this INVITE the proxy can't look for the domain in "From", but in domain of "PAI" header.

It could be nice if this would work:

is_domain_local($(hdr(P-Preferred-Identity){uri.host})) { route(4) ; Auth route }

But unfortunatelly it doesn't work since it's not a variable containing just: sip:user@domain but: "Display name" sip:user@domain

so it's not possible :(

I'll open a feature request :)

On Sunday 20 January 2008 21:56:57 Juha Heinanen wrote:

Iñaki Baz Castillo writes:

...

It could be nice if this would work:

is_domain_local($(hdr(P-Preferred-Identity){uri.host})) { route(4) ; Auth route }

But unfortunatelly it doesn't work since it's not a variable containing just: sip:user@domain but: "Display name" sip:user@domain

i remember adding pvars for some ppi header components.

I didn't know it, thanks!

There are: $pu - reference to URI in request's P-Preferred-Identity heade $pU - reference to user in request's P-Preferred-Identity header $pd - reference to domain in request's P-Preferred-Identity header $pn - reference to Display Name in request's P-Preferred-Identity header

:)